Re: Optimize LISTEN/NOTIFY
От | Joel Jacobson |
---|---|
Тема | Re: Optimize LISTEN/NOTIFY |
Дата | |
Msg-id | 8aeae418-92a6-4bbd-9c06-9574c79e59f7@app.fastmail.com обсуждение исходный текст |
Ответ на | Re: Optimize LISTEN/NOTIFY (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Optimize LISTEN/NOTIFY
Re: Optimize LISTEN/NOTIFY |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: