Re: Optimize LISTEN/NOTIFY - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: Optimize LISTEN/NOTIFY
Date
Msg-id 6070e73e-9a1d-48e2-bd5f-d69623dc8e1f@app.fastmail.com
Whole thread Raw
In response to Re: Optimize LISTEN/NOTIFY  ("Joel Jacobson" <joel@compiler.org>)
List pgsql-hackers
On Wed, Nov 12, 2025, at 21:37, Joel Jacobson wrote:
> Sequence of events:
>
> 1. In the notifier, PreCommit_Notify calls asyncQueueAddEntries,
> which updates QUEUE_HEAD when the page is full,
> (and sets queueHeadAfterWrite to this value).
>
> 2. At this time, a listener wakes up and asyncQueueAddEntries

Correction:
I meant "asyncQueueReadAllNotifications" here, not "asyncQueueAddEntries".

> reads the current QUEUE_HEAD value and stores it
> in its local `head` variable, and starts reading up to this pos.
>
> 3. In the notifier, PreCommit_Notify calls asyncQueueAddEntries
> the second time, which updates QUEUE_HEAD,
> and sets queueHeadAfterWrite to the final value
> before returning.
>
> For this reason, I think the listener could actually stop
> in between queueHeadBeforeWrite and queueHeadAfterWrite,
> since it's local `head` variable could get the intermediary
> QUEUE_HEAD value, when a page is full.

/Joel



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Trying out read streams in pgvector (an extension)
Next
From: Nathan Bossart
Date:
Subject: Re: Improve LWLock tranche name visibility across backends