From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Testing LISTEN/NOTIFY more effectively
In-reply-to: <20190727235105.7dgzj5vhaok547ut@alap3.anarazel.de>
References: <31304.1564246011@sss.pgh.pa.us>
 <20190727174202.jiwr4jgp3x7gvp22@alap3.anarazel.de>
 <5720.1564249986@sss.pgh.pa.us> <29162.1564266052@sss.pgh.pa.us>
 <20190727231826.g34yqkzj53ey46tl@alap3.anarazel.de>
 <10166.1564270037@sss.pgh.pa.us>
 <20190727235105.7dgzj5vhaok547ut@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sat, 27 Jul 2019 16:51:05 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <20276.1564272133.1@sss.pgh.pa.us>
Date: Sat, 27 Jul 2019 20:02:13 -0400
Message-ID: <20277.1564272133@sss.pgh.pa.us>
Precedence: bulk

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