Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vGxAo-0097pR-VY for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Nov 2025 10:24:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1vGxAn-00706p-OC for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Nov 2025 10:24:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1vGxAn-00706h-EP for pgsql-hackers@lists.postgresql.org; Thu, 06 Nov 2025 10:24:56 +0000 Received: from fout-b6-smtp.messagingengine.com ([202.12.124.149]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vGxAk-006Hse-03 for pgsql-hackers@postgresql.org; Thu, 06 Nov 2025 10:24:56 +0000 Received: from phl-compute-07.internal (phl-compute-07.internal [10.202.2.47]) by mailfout.stl.internal (Postfix) with ESMTP id 1E8FF1D00178; Thu, 6 Nov 2025 05:24:52 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-07.internal (MEProxy); Thu, 06 Nov 2025 05:24:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kurilemu.de; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to; s=fm1; t=1762424691; x= 1762511091; bh=SB9CLwYBCQ7KNH+ZGi3GtbbZnZN57vRgaYCH8W4VyIc=; b=r q+LFe4hcv0aom0VKIoBlbGSbXAWoms9y6Uuvg+RT+lgLddme+geunlC4vRionkN7 KWvQ8Ylkbqej+Kyo7+1/igsZZ3eu1clgjY3KFpr/tDS8pUC7VtMafpb0jeIuAgLq jolyiCZw5SH9yzRzug0+E06HEXYaFTBWy6ardOrbzfoANzOpJkm7TzZxpd5bvqGK kQYkXzd1sPk6ppEQGCMIOgBKEy8i1BdcSfeYuFqh/NOBYNqqauek87MO7BfwcnOx 0uXXY2p+7oPZoXjnUXGws5vwGH/OKDtaxa5BLNO7DepFJZSY24KdMX6O7kjVGWfx iZz35BKe7D/GlSptH4Fyg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:subject:subject:to:to:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1762424691; x=1762511091; bh=S B9CLwYBCQ7KNH+ZGi3GtbbZnZN57vRgaYCH8W4VyIc=; b=pQf43x+GFidtVB2he gJ43vAUrR8nKo3ePIBjG/6YeIZVlDN7FgIdy9wQfXBdQUNMfhyZqDqtcof1VkJ+f 7l9YTB5Yddb6QGt5Pix7wMftHbAcP9tlctbavBddu+OnpsTrwWebSQ4PKzlcdAaj 2hitZZ+pUihMiR5sL6Xp2Hrt4CZgBLTlj4wauxGNbuEfIFyZHXu7tr7Yf7RenKcF yvxQDEHpYGIpau/7EiYHhKLxNuE43aAb76mhLaBa4nP0BAg1G3bNLkHu8POBVD11 /5LqeEPJ2+PZ1KWphISw5YlRfqveDA9bnnIllFiSlTYtk/9I8HyBAIFopWb8J3fT id3fw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddukeeiheefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkgggtugfgjgesthekredttddtjeenucfhrhhomheplmhlvhgrrhho ucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsehkuhhrihhlvghmuhdruggvqeenucggtf frrghtthgvrhhnpefgudfhueekieehhffhgedujeetueehveehuefhhedvjeevueejheeg keduffdtveenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmpdhslhgrsh hhughothdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpegrlhhvhhgvrhhrvgeskhhurhhilhgvmhhurdguvgdpnhgspghrtghpthhtoh epgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhhovghlsegtohhmphhilhgv rhdrohhrghdprhgtphhtthhopehhlhhinhhnrghkrgesihhkihdrfhhipdhrtghpthhtoh epphhgshhqlhdqhhgrtghkvghrshesphhoshhtghhrvghsqhhlrdhorhhgpdhrtghpthht ohepthhglhesshhsshdrphhghhdrphgrrdhush X-ME-Proxy: Feedback-ID: ie3de48e3:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 6 Nov 2025 05:24:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kurilemu.de; s=schmee; t=1762424690; bh=W/FaXeTsYxGrJbiHP4Y201GSpOcH3ZEXYjhch5TG2MI=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=HzUrqcuj1/mFYvw+mYAzKSgQ9CErHqTiSUg1Mk7oqSzozfGtuyknxuv5EZ5lEM+cE x8HMnUvRr07jYsGrJu+7AImlpw3Ado87oWndnDXchScQ9o7+S5AuFdViJ84v/AsOof 112XbjrnUGrRAAl6FP9RsMA6i1EkfPlJAJTBK7tlEYqdxz2OoPsrXu5o+myRJYXDCp R1+Q0Vt5b5vure09ywe9edcpKnKMU8vozANyD6ByoseXzHZ7DSSGACdVAyWH72u49H C11iZ7eMOEg528Ph1SK7GRcIqkjRWqf5B7kI8yJiN+T2bIjsBiRbhd83CSRXHX6+z1 VPCPXcf0bYLOg== Received: by schmee.kurilemu.internal (Postfix, from userid 1000) id 26CDA76; Thu, 06 Nov 2025 12:24:50 +0200 (EET) Date: Thu, 6 Nov 2025 11:24:50 +0100 From: =?utf-8?Q?=C3=81lvaro?= Herrera To: Heikki Linnakangas Cc: Joel Jacobson , Tom Lane , pgsql-hackers Subject: Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue Message-ID: <202511061018.gpkyckin2ixx@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <66213fee-00ff-4952-802d-c06454e521ac@iki.fi> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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)