From: | "Joel Jacobson" <joel(at)compiler(dot)org> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Optimize LISTEN/NOTIFY |
Date: | 2025-10-07 19:26:31 |
Message-ID: | 8aeae418-92a6-4bbd-9c06-9574c79e59f7@app.fastmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 7, 2025, at 20:14, Tom Lane wrote:
> "Joel Jacobson" <joel(at)compiler(dot)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
Attachment | Content-Type | Size |
---|---|---|
optimize_listen_notify-v11.patch | application/octet-stream | 22.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2025-10-07 19:34:01 | Re: Add mode column to pg_stat_progress_vacuum |
Previous Message | Sami Imseih | 2025-10-07 19:25:08 | Re: Add mode column to pg_stat_progress_vacuum |