Having spent much of the day looking at regression tests for
different bits of contrib, I was inspired to do a quick
finger exercise to add a test for contrib/tcn. When that
module was written, we didn't have a nice way to create a
test case with stable output. But now, the isolationtester
can do the job easily.
regards, tom lane
diff --git a/contrib/tcn/.gitignore b/contrib/tcn/.gitignore
new file mode 100644
index 0000000000..b4903eba65
--- /dev/null
+++ b/contrib/tcn/.gitignore
@@ -0,0 +1,6 @@
+# Generated subdirectories
+/log/
+/results/
+/output_iso/
+/tmp_check/
+/tmp_check_iso/
diff --git a/contrib/tcn/Makefile b/contrib/tcn/Makefile
index 2de3425bbd..f36e6beddd 100644
--- a/contrib/tcn/Makefile
+++ b/contrib/tcn/Makefile
@@ -6,6 +6,8 @@ EXTENSION = tcn
DATA = tcn--1.0.sql
PGFILEDESC = "tcn - trigger function notifying listeners"
+ISOLATION = tcn
+
ifdef USE_PGXS
PG_CONFIG = pg_config
PGXS := $(shell $(PG_CONFIG) --pgxs)
diff --git a/contrib/tcn/expected/tcn.out b/contrib/tcn/expected/tcn.out
new file mode 100644
index 0000000000..8c671134ac
--- /dev/null
+++ b/contrib/tcn/expected/tcn.out
@@ -0,0 +1,13 @@
+Parsed test spec with 1 sessions
+
+starting permutation: listen insert insert2 update delete
+step listen: LISTEN mychannel;
+step insert: INSERT INTO mytable VALUES(1, 'one');
+s1: NOTIFY "mychannel" with payload ""mytable",I,"key"='1'" from s1
+step insert2: INSERT INTO mytable VALUES(2, 'two');
+s1: NOTIFY "mychannel" with payload ""mytable",I,"key"='2'" from s1
+step update: UPDATE mytable SET value = 'foo' WHERE key = 2;
+s1: NOTIFY "mychannel" with payload ""mytable",U,"key"='2'" from s1
+step delete: DELETE FROM mytable;
+s1: NOTIFY "mychannel" with payload ""mytable",D,"key"='1'" from s1
+s1: NOTIFY "mychannel" with payload ""mytable",D,"key"='2'" from s1
diff --git a/contrib/tcn/specs/tcn.spec b/contrib/tcn/specs/tcn.spec
new file mode 100644
index 0000000000..8720398139
--- /dev/null
+++ b/contrib/tcn/specs/tcn.spec
@@ -0,0 +1,29 @@
+# Tests for contrib/tcn
+
+# These tests use only self-notifies within a single session,
+# which are convenient because they minimize timing concerns.
+# Whether the NOTIFY mechanism works across sessions is not
+# really tcn's problem.
+
+setup
+{
+ CREATE EXTENSION tcn;
+ CREATE TABLE mytable (key int PRIMARY KEY, value text);
+ CREATE TRIGGER tcntrig AFTER INSERT OR UPDATE OR DELETE ON mytable
+ FOR EACH ROW EXECUTE FUNCTION triggered_change_notification(mychannel);
+}
+
+teardown
+{
+ DROP TABLE mytable;
+}
+
+session s1
+step listen { LISTEN mychannel; }
+step insert { INSERT INTO mytable VALUES(1, 'one'); }
+step insert2 { INSERT INTO mytable VALUES(2, 'two'); }
+step update { UPDATE mytable SET value = 'foo' WHERE key = 2; }
+step delete { DELETE FROM mytable; }
+
+
+permutation listen insert insert2 update delete
