Horton

Re: NOTIFY does not work as expected

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Andrey <parihaaraka@gmail.com>, Pg Bugs <pgsql-bugs@postgresql.org>
Date: 2018-07-03T18:27:04Z
Lists: pgsql-bugs 
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.

> 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

Commits

  1. Client-side fixes for delayed NOTIFY receipt.

  2. Server-side fix for delayed NOTIFY and SIGTERM processing.

  3. Introduce and use infrastructure for interrupt processing during client reads.