Feedback-ID: ic6394509:Fastmail
MIME-Version: 1.0
Date: Wed, 29 Oct 2025 18:13:16 +0100
From: "Joel Jacobson" <joel@compiler.org>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Heikki Linnakangas" <hlinnaka@iki.fi>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Message-Id: <9d93c1ee-5225-44ee-822f-e097190f1ac2@app.fastmail.com>
In-Reply-To: <2759499.1761756503@sss.pgh.pa.us>
References: <DDOYDH17RU0G.1R4MKAZKP87QV@gmail.com>
 <202510221548.tgggefdrlpo3@alvherre.pgsql>
 <DDP0YT14VYUG.34K8AP6EHU2TR@gmail.com>
 <CAD21AoBKTF9SKSANX3xeXV9NjyDGYJeYEFN4duf--Tk=_exTYQ@mail.gmail.com>
 <CAE7r3MJK9irHqpZ9vfRmz-BZSjwq4oyjR4ppmaMp2g2GePf55g@mail.gmail.com>
 <DDQZBKAC1KZ4.3LT22J6Q74JV0@gmail.com>
 <CAE7r3MJgJj4D_6mPHMr-4xCrYK7q04M3jM1J_=4baphjA2WeBA@mail.gmail.com>
 <149c402d-54c9-48dd-a730-2f5b958f2129@app.fastmail.com>
 <769bbdba-f86f-44ad-abad-f6ea4f74e3f2@iki.fi>
 <2297af80-dd5d-4fcc-815b-75bd64b00bf9@app.fastmail.com>
 <2759499.1761756503@sss.pgh.pa.us>
Subject: Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async
 queue
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/9d93c1ee-5225-44ee-822f-e097190f1ac2%40app.fastmail.com>
Precedence: bulk

On Wed, Oct 29, 2025, at 17:48, Tom Lane wrote:
> However ... that won't actually work, the reason being that
> asyncQueueProcessPageEntries() doesn't work directly from an SLRU page
> but from a local copy.  Even if it were to modify the state of that
> copy, no other backend would see the effects.
>
> The reason it's like that is stated in the comments:
>
>  * The current page must have been fetched into page_buffer from shared
>  * memory.  (We could access the page right in shared memory, but that
>  * would imply holding the SLRU bank lock throughout this routine.)
>
> The patch proposed here likewise appears to involve holding an SLRU
> bank lock throughout what could be a significant number of
> TransactionIdDidCommit tests.  That seems like it could result in a
> pretty bad "burp" in NOTIFY throughput.  That problem is ameliorated
> by only doing it when VACUUM is trying to advance datfrozenxid, but
> still I wonder if we can't find a less concurrency-unfriendly answer.
...
> All of this is a problem mainly because of the presumption that
> holding an SLRU bank lock for a long time is bad.  I wonder how
> dangerous that really is.

Ops. Sounds scary.

I don't know if others have looked at the v12-vacuum_notify_queue_cleanup
approach; if it's bad, it would be helpful to understand why.

/Joel