Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
Subject: Re: Optimize LISTEN/NOTIFY
From: Chao Li <li.evan.chao@gmail.com>
In-Reply-To: <38574cad-e90d-47b7-a015-753bb6bbc360@app.fastmail.com>
Date: Mon, 27 Oct 2025 09:27:58 +0800
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <66631FB7-5BEA-4ED5-A694-9AD8B9CCFEE8@gmail.com>
References: <6899c044-4a82-49be-8117-e6f669765f7e@app.fastmail.com>
 <165530.1752362320@sss.pgh.pa.us>
 <02a7cd37-e2fc-4212-8b19-f8c239c95fb8@app.fastmail.com>
 <e396ecf3-4227-4918-b9ff-e9568dcebcf0@app.fastmail.com>
 <b6a427fe-2ed6-4568-85d9-207a68172617@app.fastmail.com>
 <CAK80=jhmE40KVqQ3ho37MArS7cAED1p9m7uikDxcnDmqdW7t8A@mail.gmail.com>
 <96f00bf1-cc9d-4520-9d02-9e14e7767c88@app.fastmail.com>
 <30c2aa7d-dd6c-4b68-a2e4-f217a1a34acf@app.fastmail.com>
 <CA+hUKGLrMGkWDB0cwTa0RqD+AF7O-Ywgck8aVYKwOQnZgYRRug@mail.gmail.com>
 <0b4d402a-9ac2-4aa8-acf8-8231dbe579ea@app.fastmail.com>
 <c8e84bb2-d2e5-4a77-b547-3a93c5778e7e@app.fastmail.com>
 <3095599.1758644879@sss.pgh.pa.us>
 <0dc6a2cc-5216-4dc1-9dd2-430cafc6095b@app.fastmail.com>
 <E7D8A5CD-C445-4713-B6B7-6CC1D3A71161@gmail.com>
 <baf71275-9083-41be-ae13-f80821541a1a@app.fastmail.com>
 <52CC167F-763B-4ECA-B0B4-DAB381816828@gmail.com>
 <d35a114d-204a-4b40-9284-06749532b724@app.fastmail.com>
 <9186C6D0-F7A9-482A-9183-89E530B57E36@gmail.com>
 <da0996!!!!!!d8-ecf9-490d-bbd0-2a5bdb5b115a@app.fastmail.com>
 <D1CF7CA5-213A-4FC1-86DB-052D58904A0A@gmail.com>
 <cad78ff4-aae9-4c1c-8e16-ff0ccd4957f1@app.fastmail.com>
 <1073593.1759423179@sss.pgh.pa.us>
 <4bd5e6c4-6fa7-44bb-869d-59a32a331fa8@app.fastmail.com>
 <CAFY6G8dap-bCnAnMG-2Gzew8yv2Vbi9gsx9+yszKMmd57ygfvA@mail.gmail.com>
 <85828f29-e72e-4400-94f3-9a69bc8dc239@app.fastmail.com>
 <2495353.1759860890@sss.pgh.pa.us>
 <8aeae418-92a6-4bbd-9c06-9574c79e59f7@app.fastmail.com>
 <2531672.1759868124@sss.pgh.pa.us>
 <474efa78-337c-41cd-a73a-f845a0115109@app.fastmail.com>
 <2749343.1759949176@sss.pgh.pa.us>
 <8bfca2be-1ec0-4e15-aafb-0b7b661fe936@app.fastmail.com>
 <9eba307f-f2fb-48f0-9507-2e197f39ef9e@app.fastmail.com>
 <cde2a91d-d47a-43b5-ab27-f98aa739d38e@app.fastmail.com>
 <8c71183a-0d28-4bcf-a806-78446ff95404@app.fastmail.com>
 <1009807.1760476747@sss.pgh.pa.us>
 <1F7227F5-C33D-4E2C-8511-33F1468590D0@gmail.com>
 <0a5a20d3-4621-46b3-b2ab-903f63a20dea@app.fastmail.com>
 <6F913129-ABEF-4004-AAF3-F22FC34!29AE8@gmail.com>
 <cbabbb45-ec27-47f1-a8f3-eb29073e9aef@app.fastmail.com>
 <ceab2c54-3463-4029-a7d8-895a617bb457@app.fastmail.com>
 <1547585.1760645808@sss.pgh.pa.us>
 <b8df8040-1b15-4a1a-b5f6-74acebbd2d0c@app.fastmail.com>
 <CAE7r3MLivh1sHWF06hrVXkiQbw-KChPcQsh+9CheXprm5vRVMQ@mail.gmail.com>
 <14865EB6-0BF4-462B-9072-10BDAC10C052@gmail.com>
 <CAE7r3MK-3AOdh1mpZ8hw9h6F_i0D5RMoAy7CttnfCJRpB8GJDA@mail.gmail.com>
 <0BCA1C2D-B92C-459E-B1A6-6D06BA4C62CF@gmail.com>
 <55d24cbb-e9ef-491f-a99b-b3dbd7cecdf9@app.fastmail.com>
 <38574cad-e90d-47b7-a015-753bb6bbc360@app.fastmail.com>
To: Joel Jacobson <joel@compiler.org>
Archived-At: 
 <https://www.postgresql.org/message-id/66631FB7-5BEA-4ED5-A694-9AD8B9CCFEE8%40gmail.com>
Precedence: bulk


> On Oct 27, 2025, at 07:24, Joel Jacobson <joel@compiler.org> wrote:
>=20
> Write-up of changes since v20:
>=20
> Two new fields have been added to QueueBackendStatus:
> + QueuePosition advisoryPos; /* safe skip-ahead position */
> + bool advancingPos; /* backend is reading the queue */
>=20
> These are used SignalBackends and asyncQueueReadAllNotifications to
> handle the empheral state of the shared queue position, since we don't
> take a lock while advancing it in asyncQueueReadAllNotifications.
>=20
> In SignalBackends, we now don't signal laggers in other databases,
> instead we will signal any listening backend that could possibly be
> behind the old queue head, since we can't know if such backend is
> interested in the notifications before the old queue head.  Realistic
> benchmarks will be needed to determine if this happens often enough to
> warrant a more complex optimization, such as the ranges idea suggested
> by Arseniy Mukhin.
>=20
> In SignalBackends, if a backend that is uninterested in our
> notifications, has a shared pos that is at the old queue head, then we
> will check if it's not currently advancing its pos, in which case we =
can
> set its shared pos to the new queue head, i.e. "direct advance" it,
> otherwise, if it's currently advancing its pos, and if its advisory =
pos
> is behind our new queue head, we will update its advisory pos to our =
new
> queue head.
>=20
> In asyncQueueReadAllNotifications, we start by setting wakupPending to
> false and advisoryPos to true, to indicate that we've woken up, and =
that
> we will now start advancing the pos.  We also check if the pos is =
behind
> the advisory pos, and if so use the advisory pos to update the pos.
>=20
> In asyncQueueReadAllNotifications's PG_FINALLY block, we reset
> advancingPos to false, and detect if the advisoryPos was set by
> SignalBackends while we were processing messages on the queue, and if
> so, and if the advisoryPos is ahead of our pos, we update our shared =
pos
> with the advisoryPos, and otherwise update the shared pos with the new
> pos.
>=20
> =
/Joel<0001-optimize_listen_notify-v21.patch><0002-optimize_listen_notify-v=
21.patch>

I did a quick review on v21 only focusing on the =E2=80=9Cdirect =
advancement=E2=80=9D logic.

In v21, you added advisoryPos and advancingPos which is same as my =
proposed solution. But you missed an important point from mine.

Let=E2=80=99s say listener L1 is doing a slow advancing, because the =
last notifier pushed a bunch of notifications and L1 is interesting in =
them, say current QUEUE_HEAD is QH1. So, L1 is reading till reaching =
QH1.

Now notifier N1 comes. To N1, posBeforeWrite is QH1, and say =
posAfterWrite is QH2. In this case, as L1 is reading, if N1 knows that =
L1 will read till QH1, then N1 can still set L1=E2=80=99s advisoryPos to =
QH2, right? =46rom this perspective, we need to add a new field =
adviancingTillPos to QueueBackendStatus. (This field was also missing =
from my proposed patch).

Then notifier N2 comes after N1. To N2, posBeforeWrite is QH2, and say =
posAfterWrite is QH3. As L1 is still reading, and it=E2=80=99s =
advisoryPos is QH2, so N2 can also advance L1=E2=80=99s advisoryPos to =
QH3.

Finally, L1 finished reading and reached QH1. Now it sees advisoryPos is =
QH3, then it can directly bump its pos to QH3.

Do you think this logic is valid?

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/