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

From Álvaro Herrera
Subject Re: Race conditions in logical decoding
Date
Msg-id 202603201543.t6gxppyyk66p@alvherre.pgsql
Whole thread Raw
In response to Re: Race conditions in logical decoding  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,

I realized that I hadn't posted the patch version I described somewhere
downthread.  Here it is, as 0001.

While thinking about it for posting just now, I wondered if it would
work to consider that any transaction whose commit record has been
decoded but which nevertheless gets a true return from
TransactionIdIsInProgress(), just is not committed yet and so should be
omitted from the xip array of the snapshot.  That is, if it's
still-running, then we just don't copy it into the output snapshot.
That's implemented as 0002 here.  This seems somehow less controversial,
as we don't have to test TransactionIdDidCommit() for a transaction that
we haven't seen as not-running per PGPROC; and it should also be faster,
because we don't have to wait for anybody to commit.  However it gives
me pause that perhaps the snapshot would not be fully correct.  (Indeed
there are a few failing tests in the subscription suite).

Failing other ideas, I think we should just go with 0001.  We'd need more
commentary on why is TransactionIdDidCommit() OK, when we haven't
scanned PGPROC for that xid, though.

Thanks,

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"El que vive para el futuro es un iluso, y el que vive para el pasado,
un imbécil" (Luis Adler, "Los tripulantes de la noche")

Attachment

pgsql-hackers by date:

Previous
From: Henson Choi
Date:
Subject: Re: Row pattern recognition
Next
From: Alvaro Herrera
Date:
Subject: Re: Adding REPACK [concurrently]