Feedback-ID: ie3de48e3:Fastmail
Date: Fri, 7 Nov 2025 15:14:31 +0100
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Matheus Alcantara <matheusssilv97@gmail.com>,
	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: <202511071410.52ll56eyixx7@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <a8892a0e-7660-42d1-98bb-b677f6c15069@iki.fi>
Archived-At: 
 <https://www.postgresql.org/message-id/202511071410.52ll56eyixx7%40alvherre.pgsql>
Precedence: bulk

One thing I noticed while testing this is that asyncQueueAddEntries()
fills the end of a page with a dummy entry, when the next notify doesn't
fit.  However, this dummy entry contains a very valid TransactionId,
which the new freezing code will try to look up and freeze.  I think
this is somewhat bogus -- we shouldn't even try to look up that XID in
the first place.  I propose to clear it like this

@@ -1419,6 +1424,7 @@ asyncQueueAddEntries(ListCell *nextNotify)
 			 */
 			qe.length = QUEUE_PAGESIZE - offset;
 			qe.dboid = InvalidOid;
+			qe.xid = InvalidTransactionId;
 			qe.data[0] = '\0';	/* empty channel */
 			qe.data[1] = '\0';	/* empty payload */
 		}


(Line numbers do not match, because I have other local changes.)


-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"I'm always right, but sometimes I'm more right than other times."
                                                  (Linus Torvalds)
https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org/