Re: Optimize LISTEN/NOTIFY

Alexander Lakhin <exclusion@gmail.com>

From: Alexander Lakhin <exclusion@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Joel Jacobson <joel@compiler.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-04-19T04:00:00Z
Lists: pgsql-hackers
Hello Tom and Joel,

15.01.2026 20:55, Tom Lane wrote:
> Anyway, at this point I'm content to go ahead with v35, and
> I'll push that in a little bit.  Perhaps we should take a TODO
> to figure out why this test scenario runs so poorly on macOS;
> but I'll bet that the answer is not anywhere near async.c itself.

While browsing through new inconsistencies and typos, I came across one
which I'm not sure what to do with. Could you help, please?

async-notify.spec contains:
# Check ChannelHashAddListener array growth.
permutation listenc llisten l2listen l3listen lslisten

But as far as I can see, ChannelHashAddListener() was eliminated in
0002-optimize_listen_notify-v13.patch upthread [1]:

> > Or thinking a little bigger: why are we maintaining the set of
> > channels-listened-to both as a list and a hash? Could we remove
> > the list form?
>
> Yes, it was indeed possible to remove the list form.
>

So, maybe the comment or perhaps even the test case should be changed/
removed?

[1] https://www.postgresql.org/message-id/8bfca2be-1ec0-4e15-aafb-0b7b661fe936%40app.fastmail.com

Best regards,
Alexander

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Optimize LISTEN/NOTIFY via shared channel map and direct advancement.

  2. Fix incorrect logic for caching ResultRelInfos for triggers