public inbox for [email protected]  

help / color / mirror / Atom feed

From: Joel Jacobson <[email protected]>
To: Arseniy Mukhin <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Optimize LISTEN/NOTIFY
Date: Wed, 12 Nov 2025 21:37:51 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAE7r3MJyitsHSd9A-y42Cmzs5gmG=zJH2pqMytSVzmzF4e_K9A@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAK80=jhmE40KVqQ3ho37MArS7cAED1p9m7uikDxcnDmqdW7t8A@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CA+hUKGLrMGkWDB0cwTa0RqD+AF7O-Ywgck8aVYKwOQnZgYRRug@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAFY6G8dap-bCnAnMG-2Gzew8yv2Vbi9gsx9+yszKMmd57ygfvA@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAE7r3MLivh1sHWF06hrVXkiQbw-KChPcQsh+9CheXprm5vRVMQ@mail.gmail.com>
	<[email protected]>
	<CAE7r3MK-3AOdh1mpZ8hw9h6F_i0D5RMoAy7CttnfCJRpB8GJDA@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAE7r3MJxxycYwDFJdTJ+HmzeNJ_JGKyr4HpT5njN1ouVX56OUg@mail.gmail.com>
	<[email protected]>
	<CAE7r3MJ0VoAJzdLzX0dgfPJpBJxW+wg_pYaCi6mQJi47+qukhg@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAE7r3MJyitsHSd9A-y42Cmzs5gmG=zJH2pqMytSVzmzF4e_K9A@mail.gmail.com>

On Wed, Nov 12, 2025, at 17:57, Arseniy Mukhin wrote:
> On Tue, Nov 11, 2025 at 7:35 PM Joel Jacobson <[email protected]> wrote:
>> I'm therefore attaching v24 again, but renamed to v26.
>
> Thank you for the new version!

Thanks for reviewing!

> I read direct advancement part of v26, one point about it:
>
> The comment in SignalBackend says:
>
>            * Listening backends that are not advancing and are stationary at
>            * a position somewhere in the range we just wrote, can safely be
>            * direct advanced to the new queue head, since we know that they
>            * are not interested in our messages.
>            */
>
> IIUC it's impossible for the listener to stop somewhere in between
> queueHeadBeforeWrite and queueHeadAfterWrite. If the listener has
> managed to read the first notification from the notifier, it means the
> notifier transaction is complete and the listener should stop only
> after reading all notifications (so we should always see pos =
> queueHeadAfterWrite or further).

Here is what I think can happen:

If the notifications written by the notifier fills the current page,
it updates QUEUE_HEAD, and if a listening backend then
enters asyncQueueReadAllNotifications at this time,
it will set its local `head` variable to the current QUEUE_HEAD,
and when the notifier continues filling the next page,
it will again update QUEUE_HEAD, and PreCommit_Notify
will overwrite queueHeadAfterWrite with the QUEUE_HEAD.

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
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

view thread (118+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Optimize LISTEN/NOTIFY
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox