Re: NOTIFY does not work as expected

On Tue, Jul 3, 2018 at 12:53 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:

> On Tue, Jul 3, 2018 at 12:30 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>
>> On Tue, Jul 3, 2018 at 1:28 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>>> Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
>>> > On Mon, Jul 2, 2018 at 4:33 PM, Andrey <parihaaraka(at)gmail(dot)com> wrote:
>>> >> [ delayed receipt of notifications ]
>>>
>>> > I don't think this is a bug. I don't see that the docs promise one
>>> > behavior over the other, so it is really a dealer's choice. Also, I
>>> can't
>>> > reliably reproduce the reported 9.6.2 behavior on my own 9.6.2 server.
>>>
>>> FWIW, it looks like a bug to me. I don't have time to investigate
>>> further right now, though. It's also not at all clear whether the
>>> issue is in the server or libpq or psql ...
>>>
>>
>> In my hands, it bisects down to this:
>>
>> commit 4f85fde8eb860f263384fffdca660e16e77c7f76
>> Author: Andres Freund <andres(at)anarazel(dot)de>
>> Date: Tue Feb 3 22:25:20 2015 +0100
>>
>> Introduce and use infrastructure for interrupt processing during
>> client reads.
>>
>> But that was committed in 9.5.dev, not between 9.6.2 and 9.6.9.
>>
>> It is on the server side. This is testing with psql, and it doesn't seem
>> to matter which version of it. Maybe there is something between 9.6.2 and
>> 9.6.9 that shows up with another client or more.
>>
>
> 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.
>

It looks like I was wrong here. The 2nd packet with the async message is
not generally sent immediately, the server backend can hold it up until the
next time it either hears from the frontend, or until it gets a SIGUSR1 due
to another incoming NOTIFY.

But I still see this undesired behavior showing up in 9.5dev in the
mentioned commit, not showing up between 9.6.2 and 9.6.9.

Cheers,

Jeff