Re: Race conditions in logical decoding

From: Antonin Houska <ah(at)cybertec(dot)at>
To: alvherre(at)kurilemu(dot)de
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Race conditions in logical decoding
Date: 2026-01-23 06:33:32
Message-ID: 3805.1769150012@localhost
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:

> I think this algorithm is strange -- if you do have to wait more than
> once for one transaction, it would lead to doing the
> TransactionIdDidCommit again times for _all_ transactions by starting
> the inner loop from scratch, which sounds really wasteful. Why not nest
> the for() loops the other way around?

I'm quite sure I wanted to iterate through committed.xnt in the outer loop,
but probably got distracted by something else and messed things up.

> Something like this perhaps,
>
> for (int i = 0; i < builder->committed.xcnt; i++)
> {
> for (;;)
> {
> if (TransactionIdDidCommit(builder->committed.xip[i]))
> break;
> else
> {
> (void) WaitLatch(MyLatch,
> WL_LATCH_SET, WL_TIMEOUT, WL_EXIT_ON_PM_DEATH,
> 10L,
> WAIT_EVENT_SNAPBUILD_CLOG);
> ResetLatch(MyLatch);
> }
> CHECK_FOR_INTERRUPTS();
> }
> }
>
> This way you wait repeatedly for one transaction until it is marked
> committed; and once it does, you don't test it again.

Sure, that's much beter. Thanks.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2026-01-23 06:45:38 Re: Extended Statistics set/restore/clear functions.
Previous Message VASUKI M 2026-01-23 06:33:27 Re: Optional skipping of unchanged relations during ANALYZE?