pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: Matheus Alcantara <matheusssilv97@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
To: Matheus Alcantara <matheusssilv97@gmail.com>
To: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>
Cc: Joel Jacobson <joel@compiler.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
Date: Wed, 05 Nov 2025 16:02:52 -0300
Message-ID: <DE0ZSWLWHUK8.VCJU1UPD7RFP@gmail.com> (raw )
In-Reply-To: <f267b7f5-bb8d-47b6-a76a-8107be9ad032@iki.fi >
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 >
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
> notifications that we have buffered in the local buffer but haven't
> passed to NotifyMyFrontEnd() yet. On 'master', you only lose a single
> 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
> TransactionIdDidCommit.
>
> IMHO we should just make these errors FATAL. TransactionIdDidCommit()
> should not really fail, after fixing the bug we're discussing.
> NotifyMyFrontEnd() could fail on OOM, but that seems pretty unlikely on
> an otherwise idle connection. Or it could fail if the client connection
> is lost, but then the backend is about to die anyway. And arguably
> closing the connection is better than losing even a single notification,
> 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?
--
Matheus Alcantara
EDB: http://www.enterprisedb.com
view thread (99+ messages) latest in thread
Message-ID: <DE0ZSWLWHUK8.VCJU1UPD7RFP@gmail.com>
Permalink: ../DE0ZSWLWHUK8.VCJU1UPD7RFP@gmail.com/
Also on: postgresql.org/message-id/DE0ZSWLWHUK8.VCJU1UPD7RFP@gmail.com
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: matheusssilv97@gmail.com, hlinnaka@iki.fi, arseniy.mukhin.dev@gmail.com, joel@compiler.org, tgl@sss.pgh.pa.us
Subject: Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
In-Reply-To: <DE0ZSWLWHUK8.VCJU1UPD7RFP@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox