Re: Optimize LISTEN/NOTIFY

From: "Joel Jacobson" <joel(at)compiler(dot)org>
To: "Arseniy Mukhin" <arseniy(dot)mukhin(dot)dev(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimize LISTEN/NOTIFY
Date: 2025-11-12 20:53:17
Message-ID: 6070e73e-9a1d-48e2-bd5f-d69623dc8e1f@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-11-12 21:00:02 Re: Improve LWLock tranche name visibility across backends
Previous Message Melanie Plageman 2025-11-12 20:44:14 Re: Trying out read streams in pgvector (an extension)