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
