Re: Optimize LISTEN/NOTIFY

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Joel Jacobson <joel(at)compiler(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimize LISTEN/NOTIFY
Date: 2026-04-19 04:00:00
Message-ID: 037ce9cd-28ad-4c19-9be1-d8c1f577a322@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message JoongHyuk Shin 2026-04-19 05:46:57 [PATCH] Prevent repeated deadlock-check signals in standby buffer pin waits
Previous Message Paul A Jungwirth 2026-04-18 23:18:13 Re: SQL:2011 Application Time Update & Delete