This patch adds some primitive regression tests for the LISTEN,
NOTIFY, and UNLISTEN commands -- there were previously no regression
tests for this functionality.
There are currently two problems/caveats with the patch:
(1) The regression test can never pass, because the message that
psql produces when a signal is delivered always changes
slightly between runs of the regression tests, since the
backend's PID is not constant:
Asynchronous notification "my_cond" received from server process with
PID 15942.
How should I fix this? What we'd like to be able to say is
"ensure that the output of the command matches this regular
expression", rather than the mere equality comparison (with
allowances for whitespace, etc.) that we are using right
now.
(2) At present, we only test notifications that are delivered to
our own backend. That means we're not testing the code path
that delivers notifications to other backends (which is
probably the one more likely to contain bugs). The tests
I've written are better than nothing, but it would be nice
to be able to test this functionality more completely.
The problem with listening for signals in one backend and
delivering signals in another backend is that we need some
way to do synchronization between the backends (for example,
we don't want to execute a NOTIFY on a signal before the
other backend has had a chance to LISTEN for it). I was
thinking of implementing this by acquiring exclusive locks
on a dummy table, but that is kind of a hack, and has its
own concurrency problems (for example, we need to ensure the
CREATE TABLE precedes the LISTEN & NOTIFY tests). Any
thoughts?
One possibility is just writing a separate little C
application that does the LISTEN/NOTIFY testing itself, and
is invoked by the regression test script. The same technique
would be useful for doing some testing of VACUUM, for
example. Does anyone else think this would be useful?
#1 needs to be fixed before this patch can be applied, but #2 will
#probably remain an area for future work.
-Neil