Re: BUG #17072: Assert for clogGroupNext failed due to a race condition in TransactionGroupUpdateXidStatus()
От | Alexander Lakhin |
---|---|
Тема | Re: BUG #17072: Assert for clogGroupNext failed due to a race condition in TransactionGroupUpdateXidStatus() |
Дата | |
Msg-id | a5c5770f-4074-93b7-4c75-10a8d8d67e8f@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17072: Assert for clogGroupNext failed due to a race condition in TransactionGroupUpdateXidStatus() (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: BUG #17072: Assert for clogGroupNext failed due to a race condition in TransactionGroupUpdateXidStatus()
|
Список | 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@postgresql.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
В списке pgsql-bugs по дате отправления: