Horton

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

Álvaro Herrera <alvherre@kurilemu.de>

View thread
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Joel Jacobson <joel@compiler.org>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-11-06T10:24:50Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Clear 'xid' in dummy async notify entries written to fill up pages

  2. Fix remaining race condition with CLOG truncation and LISTEN/NOTIFY

  3. Fix bug where we truncated CLOG that was still needed by LISTEN/NOTIFY

  4. Escalate ERRORs during async notify processing to FATAL

  5. Limit the size of TID lists during parallel GIN build

Hello,

I've been studying the code for freezing of items at vacuum-truncate
time, and one thing that jumps at me is that perhaps we ought to be more
proactive in freezing items immediately as they are processed.  We can
do that for any transactions that precede RecentXmin, because by that
point, every snapshot in the system should have that committed
transaction as no longer in progress anyway. Something like

diff --git a/src/backend/commands/async.c b/src/backend/commands/async.c
index 8ac7d989641..88d5ed2b461 100644
--- a/src/backend/commands/async.c
+++ b/src/backend/commands/async.c
@@ -2038,6 +2038,11 @@ asyncQueueProcessPageEntries(volatile QueuePosition *current,
 			}
 			else if (TransactionIdDidCommit(qe->xid))
 			{
+				if (TransactionIdPrecedes(RecentXmin, qe->xid))
+				{
+					elog(WARNING, "freezing an entry for transaction %u", qe->xid);
+					qe->xid = FrozenTransactionId;
+				}
 				memcpy(local_buf_end, qe, qe->length);
 				local_buf_end += qe->length;
 			}

If we do this, then the chances that we need to freeze items at vacuum
time are much lower, and we're not creating any danger that
TransactionIdDidCommit() errors any more than we have in the current
code.

Is there any reason this wouldn't work?


I noticed that async-notify-test-3 doesn't actually freeze any items by
itself ... you need to do "ALTER TABLE template0 allow_connections" and
then do vacuumdb -a in a loop in order for this to happen (or something
similar, I guess).  Otherwise the new code in AsyncNotifyFreezeXids is
never executed.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Those who use electric razors are infidels destined to burn in hell while
we drink from rivers of beer, download free vids and mingle with naked
well shaved babes." (http://slashdot.org/comments.pl?sid=44793&cid=4647152)