Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue

On 07/11/2025 16:14, Álvaro Herrera wrote:
> 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.)

Committed. I committed the above separately, because I forgot to include
it in the main commit. Oops.

Just to summarize what was committed, out of all the different variants
discussed:

* Any ERROR while processing an async notification is now turned into FATAL
* Vacuum scans the async notification queue and freezes xids before
truncating CLOG
* The TransactionIdDidCommit() calls are now made while holding the SLRU
lock. NotifyMyFrontEnd() calls are still made after releasing the lock
* listenChannels == NIL special case is checked before
TransactionIdDidCommit(). This avoids the problem that no backend can
LISTEN to anything anymore, if there's one broken entry in the queue for
some reason
* 'xid' field on dummy entries is now set to InvalidTransactionId so
that they don't need to be frozen

Thanks everyone!

- Heikki