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 →
-
Optimize LISTEN/NOTIFY via shared channel map and direct advancement.
- 282b1cde9ded 19 (unreleased) landed
-
Fix incorrect logic for caching ResultRelInfos for triggers
- 39dcfda2d23a 19 (unreleased) cited