Horton

Re: Optimize LISTEN/NOTIFY

Joel Jacobson <joel@compiler.org>

View thread
From: "Joel Jacobson" <joel@compiler.org>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Matheus Alcantara" <matheusssilv97@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-10-07T19:26:31Z
Lists: pgsql-hackers

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

Attachments

On Tue, Oct 7, 2025, at 20:14, Tom Lane wrote:
> "Joel Jacobson" <joel@compiler.org> writes:
>>> 7. I'm wondering if we could add some TAP tests for this? I think that
>>> adding a case to ensure that we can grown the dshash correctly and also
>>> we manage multiple backends to the same channel properly. This CF [1]
>>> has some examples of how TAP tests can be created to test LISTEN/NOTIFY
>
>> I will look over the tests. Maybe we should add some elog DEBUG at the
>> new code paths, and ensure the tests at least cover all of them?
>
> I went to do a coverage test on v10, and found that it does not get
> through the existing async-notify isolation test: it panics with
> "cannot abort transaction %u, it was already committed".  It's a bit
> premature to worry about adding new tests if you're not passing the
> ones that are there.

Ops, I see I got the list_member() code wrong. I've changed it to now
create String nodes, and then use strVal().

I also changed back to dshash_find(..., false) in SignalBackends(),
since that makes more sense to me, since we're not modifying entry.
(This was the code change due to me being fooled by the false alarm from
the NetBSD animal.)

/Joel