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