| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Neil Conway <neilc(at)samurai(dot)com> |
| Cc: | PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: LISTEN/NOTIFY regression tests |
| Date: | 2003-11-20 19:35:03 |
| Message-ID: | 6137.1069356903@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Neil Conway <neilc(at)samurai(dot)com> writes:
> This patch adds some primitive regression tests for the LISTEN,
> NOTIFY, and UNLISTEN commands -- there were previously no regression
> tests for this functionality.
These cannot usefully be tested with our current regression test
methodology, as you observe in your comments.
> 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?
We have previously speculated about setting up some sort of test harness
program that can drive multiple backends through a coordinated series of
operations. This would allow realistic testing of LOCK, LISTEN/NOTIFY,
MVCV semantics, etc, so it shouldn't be single-purpose --- it should be
script-driven somehow. I think we had talked about scripts with
contents like
[to backend 1]
some SQL commands...
[to backend 2]
some SQL commands...
[to backend 1]
some more SQL commands...
but I can't recall if anyone had good ideas about how to describe the
expected output. If you search the archives you can probably find
the previous discussions --- it was a couple years ago.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-11-20 19:43:34 | Re: refactor CreateTupleDescCopy() |
| Previous Message | Neil Conway | 2003-11-20 18:24:31 | fix compile warning |