Horton

Re: Testing LISTEN/NOTIFY more effectively

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2019-07-28T00:02:13Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> Polling for notices on the blocked connection before printing anything
> ought to practically be reliable. Theoretically I think it still allows
> for some reordering, e.g. because there was packet loss on one, but not
> the other connection.

As long as it's a local connection, packet loss shouldn't be a problem
;-).  I'm slightly more worried about the case of more than one bufferful
of NOTICE messages: calling PQconsumeInput isn't entirely guaranteed to
absorb *all* available input.  But for the cases we actually need to
deal with, I think probably the patch as I sent it is OK.  We could
complicate matters by going around the loop extra time(s) to verify
that select() thinks no data is waiting, but I doubt it's worth the
complexity.

			regards, tom lane

Commits

  1. Improve test coverage for LISTEN/NOTIFY.

  2. Don't drop NOTICE messages in isolation tests.

  3. Fix isolationtester race condition for notices sent before blocking.