| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Alexander Lakhin <exclusion(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 09:55:13 |
| Message-ID: | CAA4eK1J62R6HuTDE+WDisc2Me_o0WO0ND84ixyfYekbM8su47w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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()?
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.
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Lakhin | 2021-06-25 10:00:00 | Re: BUG #17072: Assert for clogGroupNext failed due to a race condition in TransactionGroupUpdateXidStatus() |
| Previous Message | Alexander Lakhin | 2021-06-25 04:00:00 | Re: BUG #17066: Cache lookup failed when null (unknown) is passed as anycompatiblemultirange |