On 2018-07-03 14:27:04 -0400, Tom Lane wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
> > Further diagnosis here is that in the "working" case the client receives a
> > single packet from the server containing both the pg_sleep response, and
> > async response, in that order, and the client processes both of them. In
> > the "broken" case, the client receives a single packet from the server
> > containing the pg_sleep response, and processes it, and then blocks on user
> > input. The async response is immediately available in the next packet if
> > the client would ask for it, but the client doesn't do so.
>
> This suggests that 4f85fde8e introduced an extra output-flush operation
> into the code path, ie it must be flushing the output buffer to the client
> after ReadyForQuery and then again after emitting the Notify.
Hm. There's indeed a
/*
* Must flush the notify messages to ensure frontend gets them promptly.
*/
pq_flush();
in ProcessIncomingNotify(). But that was there before, too. And I don't
see any argument why it'd be a good idea to remove it?
> > If I am diagnosing the right problem, this still doesn't seem like a bug to
> > me.
>
> Well, it seems undesirable to me, both because it implies network traffic
> inefficiency and because clients don't seem to be expecting it.
A report after ~3 years doesn't strike me as a huge argument for that,
and it doesn't seem crazy to believe it'd hurt some users changing
that. And when would you avoid flushing?
> We have another recent complaint that seems to be possibly the
> same thing, bug #15255.
That seems more related to the logical replication apply code than
anything?
Greetings,
Andres Freund