Feedback-ID: ie3de48e3:Fastmail
Date: Thu, 6 Nov 2025 11:18:13 +0100
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: Matheus Alcantara <matheusssilv97@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
	Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>,
 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
Message-ID: <202511061014.6poayht26qnn@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <DE0ZSWLWHUK8.VCJU1UPD7RFP@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202511061014.6poayht26qnn%40alvherre.pgsql>
Precedence: bulk

On 2025-Nov-05, Matheus Alcantara wrote:

> 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 don't think things are supposed to work that way -- I understand that
an application that connects is supposed to read the current state of
things, and then the notifies ensure that any changes from that point on
can be processed.  So if a connection dies on a FATAL, then you have to
establish your LISTENs again and obtain the current state of the world
at that point.  It doesn't miss anything, because any NOTIFYies that
occurred while the connection was down should be obtained when current
state is read.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"This is what I like so much about PostgreSQL.  Most of the surprises
are of the "oh wow!  That's cool" Not the "oh shit!" kind.  :)"
Scott Marlowe, http://archives.postgresql.org/pgsql-admin/2008-10/msg00152.php