Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Wed, 05 Nov 2025 16:02:52 -0300
Message-Id: <DE0ZSWLWHUK8.VCJU1UPD7RFP@gmail.com>
Cc: "Joel Jacobson" <joel@compiler.org>, "Tom Lane" <tgl@sss.pgh.pa.us>,
 "pgsql-hackers" <pgsql-hackers@postgresql.org>
Subject: Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async
 queue
From: "Matheus Alcantara" <matheusssilv97@gmail.com>
To: "Heikki Linnakangas" <hlinnaka@iki.fi>, "Matheus Alcantara"
 <matheusssilv97@gmail.com>, "Arseniy Mukhin" <arseniy.mukhin.dev@gmail.com>
References: <DDOYDH17RU0G.1R4MKAZKP87QV@gmail.com>
 <CAE7r3MJK9irHqpZ9vfRmz-BZSjwq4oyjR4ppmaMp2g2GePf55g@mail.gmail.com>
 <DDQZBKAC1KZ4.3LT22J6Q74JV0@gmail.com>
 <CAE7r3MJgJj4D_6mPHMr-4xCrYK7q04M3jM1J_=4baphjA2WeBA@mail.gmail.com>
 <149c402d-54c9-48dd-a730-2f5b958f2129@app.fastmail.com>
 <769bbdba-f86f-44ad-abad-f6ea4f74e3f2@iki.fi>
 <2297af80-dd5d-4fcc-815b-75bd64b00bf9@app.fastmail.com>
 <2759499.1761756503@sss.pgh.pa.us>
 <6ae4acd3-6c57-4271-bc24-634fd1b11d67@iki.fi>
 <e1e4909b-66b9-43d8-8942-529b7519c758@app.fastmail.com>
 <c37cae90-0564-4798-89e1-5dfb8c6d2cba@app.fastmail.com>
 <dc6b131d-b010-401e-951e-48535bfb5861@iki.fi>
 <badd3b04-ce9f-4f29-9b42-05e5cc545058@iki.fi>
 <68079c62-2fe9-4489-b68d-3b1b911ebd59@app.fastmail.com>
 <66213fee-00ff-4952-802d-c06454e521ac@iki.fi>
 <CAE7r3M+ZE1UR7cC1bTsesFLzP1v24=Hk1kwBRuqDmJsrTNMuRA@mail.gmail.com>
 <fedbd908-4571-4bbe-b48e-63bfdcc38f64@iki.fi>
 <CAFY6G8etx0ZE51p59UHKBEZ7L3WMnmxp7v4xEDVHQdRp2UqhyA@mail.gmail.com>
 <f267b7f5-bb8d-47b6-a76a-8107be9ad032@iki.fi>
In-Reply-To: <f267b7f5-bb8d-47b6-a76a-8107be9ad032@iki.fi>
Archived-At: 
 <https://www.postgresql.org/message-id/DE0ZSWLWHUK8.VCJU1UPD7RFP%40gmail.com>
Precedence: bulk

On Wed Nov 5, 2025 at 9:59 AM -03, Heikki Linnakangas wrote:
>> In case of an error on TransactionIdDidCommit() I think that we will
>> have the same behavior as we advance the "current" position before of
>> DidCommit call the PG_FINALLY block will set the backend position past
>> the failing notification entry.
>
> With my patch, if TransactionIdDidCommit() fails, we will lose all the=20
> notifications that we have buffered in the local buffer but haven't=20
> passed to NotifyMyFrontEnd() yet. On 'master', you only lose a single=20
> notification, the one where TransactionIdDidCommit() failed.
>
Yeah, that's true.

>> How bad would be to store the notification entries within a list and
>> store the next position with the notification entry and then wrap the
>> NotifyMyFrontEnd() call within a PG_TRY and update the "current" to the
>> saved "next position" on PG_CATCH? Something like this:
>
> [ ...]
>
> That addresses the failure on NotifyMyFrontEnd, but not on=20
> TransactionIdDidCommit.
>
> IMHO we should just make these errors FATAL. TransactionIdDidCommit()=20
> should not really fail, after fixing the bug we're discussing.=20
> NotifyMyFrontEnd() could fail on OOM, but that seems pretty unlikely on=
=20
> an otherwise idle connection. Or it could fail if the client connection=
=20
> is lost, but then the backend is about to die anyway. And arguably=20
> closing the connection is better than losing even a single notification,=
=20
> anyway.
>
My only concern with making these errors FATAL is that if a notification
entry causes a different, recoverable error, all subsequent messages
will be lost. This is because if backend die and the user open a new
connection and execute LISTEN on the channel it will not see these
notifications past the one that caused the error. I'm not sure if we are
completely safe from this case of a recoverable error, what do you
think?

--=20
Matheus Alcantara
EDB: http://www.enterprisedb.com