On Fri, Nov 08, 2019 at 10:30:39AM +0900, Michael Paquier wrote:
> Per the arguments of upthread, storing a 64-bit XID would require a
> catalog change and you cannot backpatch that. I would suggest to keep
> this patch focused on HEAD, and keep it as an improvement of the
> existing features. Co
On Mon, Oct 28, 2019 at 05:17:52AM +, imai.yoshik...@fujitsu.com wrote:
> According to the commit 3c8404649 [1], transactional update in
> pg_index is not safe in non-MVCC catalog scans before PG9.4.
> But it seems to me that we can use transactional update in pg_index
> after the commit 813fb0
Hi Dhruv,
On Sun, June 30, 2019 at 7:30 AM, Goel, Dhruv wrote:
> > On Jun 10, 2019, at 1:20 PM, Goel, Dhruv wrote:
> >> On Jun 9, 2019, at 5:33 PM, Tom Lane wrote:
> >> Andres Freund writes:
> >>> On June 9, 2019 8:36:37 AM PDT, Tom Lane wrote:
> I think you are mistaken that doing transa
On Tue, Jul 9, 2019 at 10:33 AM Goel, Dhruv wrote:
> I have attached the revised patch. I ran check-world multiple times on my
> machine and it seems to succeed now. Do you mind kicking-off the CI build
> with the latest patch?
Thanks.
It's triggered automatically when you post patches to the
On Mon, Jul 8, 2019 at 9:51 AM Thomas Munro wrote:
> I noticed that check-world passed several times with this patch
> applied, but the most recent CI run failed in multiple-cic:
>
> +error in steps s2i s1i: ERROR: cache lookup failed for index 26303
>
> https://travis-ci.org/postgresql-cfbot/pos
On Sun, Jun 30, 2019 at 7:30 PM Goel, Dhruv wrote:
> > On Jun 10, 2019, at 1:20 PM, Goel, Dhruv wrote:
> >> On Jun 9, 2019, at 5:33 PM, Tom Lane wrote:
> >> Andres Freund writes:
> >>> On June 9, 2019 8:36:37 AM PDT, Tom Lane wrote:
> I think you are mistaken that doing transactional upda
Andres Freund writes:
> On June 9, 2019 8:36:37 AM PDT, Tom Lane wrote:
>> I think you are mistaken that doing transactional updates in pg_index
>> is OK. If memory serves, we rely on xmin of the pg_index row for
>> purposes such as detecting whether a concurrently-created index is safe
>> to us
Hi,
On June 9, 2019 8:36:37 AM PDT, Tom Lane wrote:
>"Goel, Dhruv" writes:
>I think you are mistaken that doing transactional updates in pg_index
>is OK. If memory serves, we rely on xmin of the pg_index row for
>purposes
>such as detecting whether a concurrently-created index is safe to use
>y
"Goel, Dhruv" writes:
> Yes, you are correct. The test case here was that if a tuple is inserted
> after the reference snapshot is taken in Phase 2 and before the index is
> marked ready. If this tuple is deleted before the reference snapshot of Phase
> 3, it will never make it to the index. I
Hello,
On Wed, May 15, 2019 at 1:45 PM Goel, Dhruv wrote:
>
>
> Proposed Solution:
>
> We remove the third wait state completely from the concurrent index build.
> When we mark the index as ready, we also mark “indcheckxmin” to true which
> essentially enforces Postgres to not use this index for
10 matches
Mail list logo
