Re: Testing LISTEN/NOTIFY more effectively

Hi,

On 2019-07-27 12:46:51 -0400, Tom Lane wrote:
> So, if we'd like to have more thorough NOTIFY coverage without going
> to that much work, what to do? I thought of a few alternatives:
>
> 1. Write a TAP test instead of using the old test frameworks, and
> use regexps to check the expected output. But this seems ugly and
> hard to get right. In particular, our TAP infrastructure doesn't
> seem to be (easily?) capable of running concurrent psql sessions,
> so it doesn't seem like there's any good way to test cross-session
> notifies that way.

It's not that hard to have concurrent psql sessions -
e.g. src/test/recovery/t/013_crash_restart.pl does so. Writing tests by
interactively controlling psql is pretty painful regardless.

I'm inclined to think that this is better tested using isolationtester
than a tap test.

> 2. Change psql so that there's a way to get NOTIFY messages without
> the sending PID. For testing purposes, it'd be sufficient to know
> whether the sending PID is our own backend's PID or not. This idea
> is not horrible, and it might even be useful for outside purposes
> if we made it flexible enough; which leads to thoughts like allowing
> the psql user to set a format-style string, similar to the PROMPT
> strings but with escapes for channel name, payload, etc. I foresee
> bikeshedding, but we could probably come to an agreement on a feature
> like that.

I was wondering about just tying it to VERBOSITY. But that'd not allow
us to see whether our backend was the sender. I'm mildly inclined to
think that that might still be a good idea, even if we mostly go with
3) - some basic plain regression test coverage of actually receiving
notifies would be good.

> 3. On the other hand, that doesn't help much for the isolation tester
> because it doesn't go through psql. In fact, AFAICS it doesn't have
> any provision for dealing with notify messages at all; probably,
> in the async-notify.spec test, the listening session builds up a
> queue of notifies that it never reads. So we could imagine addressing
> the testing gap strictly inside the isolation-tester framework, if we
> added the ability for it to detect and print notifications in a
> test-friendly format (no explicit PIDs).
>
> I'm finding alternative #3 the most attractive, because we really
> want isolation-style testing for LISTEN/NOTIFY, and this solution
> doesn't require designing a psql feature that we'd need to get
> consensus on.

Yea. I think that's really what need. As you say, the type of test we
really need is what isolationtester provides. We can reimplement it
awkwardly in perl, but there seems to be little point in doing so.
Especially as what we're talking about is an additional ~15 lines or so
of code in isolationtester.

It'd be kinda neat if we had other information in the notify
message. E.g. having access to the sender's application name would be
useful for isolationtester, to actually verify where the message came
from. But it's probably not worth investing a lot in that.

Perhaps we could just have isolationtester check to which
isolationtester session the backend pid belongs? And then print the
session name instead of the pid? That should be fairly easy, and would
probably give us all we need?

Greetings,

Andres Freund