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