From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Andrey <parihaaraka(at)gmail(dot)com>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: NOTIFY does not work as expected |
Date: | 2018-07-03 18:27:04 |
Message-ID: | 65571.1530642424@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Jeff Janes <jeff(dot)janes(at)gmail(dot)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.
> 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.
We have another recent complaint that seems to be possibly the
same thing, bug #15255.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-07-03 19:09:18 | Re: NOTIFY does not work as expected |
Previous Message | Jeff Janes | 2018-07-03 16:53:25 | Re: NOTIFY does not work as expected |