Re: Testing LISTEN/NOTIFY more effectively
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2019-07-28T16:07:41Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2019-07-27 12:46:51 -0400, Tom Lane wrote: >> 2. Change psql so that there's a way to get NOTIFY messages without >> the sending PID. For testing purposes, it'd be sufficient to know >> whether the sending PID is our own backend's PID or not. This idea >> is not horrible, and it might even be useful for outside purposes >> if we made it flexible enough; which leads to thoughts like allowing >> the psql user to set a format-style string, similar to the PROMPT >> strings but with escapes for channel name, payload, etc. I foresee >> bikeshedding, but we could probably come to an agreement on a feature >> like that. > I was wondering about just tying it to VERBOSITY. But that'd not allow > us to see whether our backend was the sender. I'm mildly inclined to > think that that might still be a good idea, even if we mostly go with > 3) - some basic plain regression test coverage of actually receiving > notifies would be good. BTW, as far as that goes, do you think we could get away with changing psql to print "from self" instead of "from PID n" when it's a self-notify? That would be enough to make the output stable for cases that we'd be able to check in the core test infrastructure. So far as the backend is concerned, doing anything there is redundant with the isolation tests I just committed --- but it would allow psql's own notify code to be covered, so maybe it's worth the trouble. regards, tom lane
Commits
-
Improve test coverage for LISTEN/NOTIFY.
- 8173fa5abb16 9.6.17 landed
- 34f66c0ed800 10.12 landed
- 7d4c3118137a 12.2 landed
- 295054411ebb 11.7 landed
- b10f40bf0e45 13.0 landed
-
Don't drop NOTICE messages in isolation tests.
- b1016834d325 12.0 landed
- ebd49928215e 13.0 landed
-
Fix isolationtester race condition for notices sent before blocking.
- 97fb88ea4a64 12.0 landed
- 30717637c1c5 13.0 landed