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
Index: src/test/regress/parallel_schedule
===================================================================
RCS file: /var/lib/cvs/pgsql-server/src/test/regress/parallel_schedule,v
retrieving revision 1.23
diff -c -r1.23 parallel_schedule
*** src/test/regress/parallel_schedule 13 Sep 2003 16:44:48 -0000 1.23
--- src/test/regress/parallel_schedule 15 Nov 2003 23:01:34 -0000
***************
*** 60,66 ****
# ----------
# The fourth group of parallel test
# ----------
! test: select_into select_distinct select_distinct_on select_implicit select_having subselect union case join aggregates transactions random portals arrays btree_index hash_index update
test: privileges
test: misc
--- 60,66 ----
# ----------
# The fourth group of parallel test
# ----------
! test: select_into select_distinct select_distinct_on select_implicit select_having subselect union case join aggregates transactions random portals arrays btree_index hash_index update notify
test: privileges
test: misc
Index: src/test/regress/serial_schedule
===================================================================
RCS file: /var/lib/cvs/pgsql-server/src/test/regress/serial_schedule,v
retrieving revision 1.22
diff -c -r1.22 serial_schedule
*** src/test/regress/serial_schedule 13 Sep 2003 16:44:48 -0000 1.22
--- src/test/regress/serial_schedule 15 Nov 2003 23:01:47 -0000
***************
*** 73,78 ****
--- 73,79 ----
test: btree_index
test: hash_index
test: update
+ test: notify
test: privileges
test: misc
test: select_views
Index: src/test/regress/sql/notify.sql
===================================================================
RCS file: src/test/regress/sql/notify.sql
diff -N src/test/regress/sql/notify.sql
*** /dev/null 1 Jan 1970 00:00:00 -0000
--- src/test/regress/sql/notify.sql 15 Nov 2003 23:06:14 -0000
***************
*** 0 ****
--- 1,51 ----
+ LISTEN my_cond;
+ NOTIFY my_cond;
+
+ BEGIN;
+ NOTIFY my_cond;
+ COMMIT;
+
+ -- notifications should not be delivered if the transaction that sends
+ -- them aborts
+ BEGIN;
+ NOTIFY my_cond;
+ ABORT;
+
+ -- multiple notifications on the same condition are compressed into a
+ -- single notification
+ BEGIN;
+
+ NOTIFY my_cond;
+ NOTIFY my_cond;
+ NOTIFY my_cond;
+
+ COMMIT;
+
+ -- UNLISTEN should be transactional as well
+ BEGIN;
+ UNLISTEN my_cond;
+ ABORT;
+
+ -- should be delivered, since the UNLISTEN txn was aborted
+ NOTIFY my_cond;
+
+ -- these two transactions should produce identical results:
+ -- whether the unlisten was executed before or after the
+ -- notify doesn't change the fact that the notification
+ -- is NOT delivered
+ BEGIN;
+ NOTIFY my_cond;
+ UNLISTEN my_cond;
+ COMMIT;
+
+ -- should NOT be delivered
+ NOTIFY my_cond;
+ LISTEN my_cond;
+
+ BEGIN;
+ UNLISTEN my_cond;
+ NOTIFY my_cond;
+ COMMIT;
+
+ -- should NOT be delivered
+ NOTIFY my_cond;
\ No newline at end of file
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
