Re: Testing LISTEN/NOTIFY more effectively - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Testing LISTEN/NOTIFY more effectively
Date
Msg-id 8147.1564330061@sss.pgh.pa.us
Whole thread Raw
In response to Re: Testing LISTEN/NOTIFY more effectively  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2019-07-27 12:46:51 -0400, Tom Lane wrote:
>> 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.

BTW, as far as that goes, do you think we could get away with changing
psql to print "from self" instead of "from PID n" when it's a self-notify?
That would be enough to make the output stable for cases that we'd be
able to check in the core test infrastructure.

So far as the backend is concerned, doing anything there is redundant
with the isolation tests I just committed --- but it would allow psql's
own notify code to be covered, so maybe it's worth the trouble.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Add parallelism and glibc dependent only options to reindexdb
Next
From: Andres Freund
Date:
Subject: Re: Add parallelism and glibc dependent only options to reindexdb