Re: Race conditions in logical decoding - Mailing list pgsql-hackers

From Antonin Houska
Subject Re: Race conditions in logical decoding
Date
Msg-id 3805.1769150012@localhost
Whole thread Raw
In response to Re: Race conditions in logical decoding  (Álvaro Herrera <alvherre@kurilemu.de>)
Responses Re: Race conditions in logical decoding
List pgsql-hackers
Álvaro Herrera <alvherre@kurilemu.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



pgsql-hackers by date:

Previous
From: VASUKI M
Date:
Subject: Re: Optional skipping of unchanged relations during ANALYZE?
Next
From: Corey Huinker
Date:
Subject: Re: Extended Statistics set/restore/clear functions.