Re: Testing LISTEN/NOTIFY more effectively

Hi,

On 2019-07-27 20:02:13 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> 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.

It'd just be one continue; right? Except that we don't know if
PQconsumeInput() actually did anything... So we'd need to do something
like executing a select and only call PQconsumeInput() if the select
signals that there's data? And then always retry? Yea, that seems too
complicated.

Kinda annoying that we don't expose pqReadData()'s return value anywhere
that I can see. Not so much for this, but in general. Travelling back
into the past, ISTM, PQconsumeInput() should have returned a different
return code if either pqReadData() or pqFlush() did anything.

I wonder if there aren't similar dangers around the notify handling. In
your patch we don't print them particularly eagerly. Doesn't that also
open us up to timing concerns? In particular, for notifies sent out
while idle, we might print them together with the *last* command
executed - as far as I can tell, if they arrive before the
PQconsumeInput(), we'll process them all in the PQisBusy() call at the
top of try_complete_step()'s loop? Am I missing some interlock here?

Greetings,

Andres Freund