Re: Testing LISTEN/NOTIFY more effectively

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Testing LISTEN/NOTIFY more effectively
Date: 2019-07-28 00:54:18
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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

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?


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-07-28 01:08:50 Re: Testing LISTEN/NOTIFY more effectively
Previous Message Bruce Momjian 2019-07-28 00:51:28 Re: pg_upgrade fails with non-standard ACL