From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #17072: Assert for clogGroupNext failed due to a race condition in TransactionGroupUpdateXidStatus() |
Date: | 2021-06-25 11:00:00 |
Message-ID: | a5c5770f-4074-93b7-4c75-10a8d8d67e8f@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hello Amit,
25.06.2021 12:55, Amit Kapila wrote:
> On Fri, Jun 25, 2021 at 12:20 AM PG Bug reporting form
> <noreply(at)postgresql(dot)org> wrote:
>> The offending (the one that leaved a "valid" clogGroupNext) proccess is
>> 60d48c2d.ea21. It looks like it got from the
>> pg_atomic_compare_exchange_u32() the nextidx value that was written in the
>> clogGroupFirst by the process 60d48c2e.ebc5, and exited just after that.
>>
> Your analysis seems to be in the right direction. Can you try by
> setting clogGroupNext to INVALID_PGPROCNO
> (pg_atomic_write_u32(&proc->clogGroupNext, INVALID_PGPROCNO);) before
> we return false in the first while(true) loop in function
> TransactionGroupUpdateXidStatus()?
With this modification that assert is not triggered, all 100 iterations
pass fine (triple checked).
> I think this should be reproducible on all branches from HEAD till
> v11. Have you tried in any other branch? I'll also try to reproduce
> it.
I've reproduced it on REL_11_STABLE, REL_12_STABLE, REL_13_STABLE, and
master.
Best regards,
Alexander
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2021-06-25 20:48:49 | Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows |
Previous Message | vignesh C | 2021-06-25 10:32:31 | Re: BUG #17072: Assert for clogGroupNext failed due to a race condition in TransactionGroupUpdateXidStatus() |