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

From Tom Lane
Subject Re: Testing LISTEN/NOTIFY more effectively
Date
Msg-id 20277.1564272133@sss.pgh.pa.us
Whole thread Raw
In response to Re: Testing LISTEN/NOTIFY more effectively  (Andres Freund <andres@anarazel.de>)
Responses Re: Testing LISTEN/NOTIFY more effectively  (Andres Freund <andres@anarazel.de>)
List 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Testing LISTEN/NOTIFY more effectively
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade fails with non-standard ACL