Re: NOTIFY does not work as expected

man: "... if a listening session receives a notification signal while it is
within a transaction, the notification event will not be delivered to its
connected client until _just after_ the transaction is completed (either
committed or aborted)."
Expected behavior is to deliver notification after pg_sleep is finished.
Currently the one may hold opened connection (being idle and listening
socket) for a long time, close it and never deliver the notification (if
was busy while being notified).
All delivering problems were about overflowed queue, merging notifications
and transactions handling. If we must not rely on delivering at all, then
NOTIFY makes no sense.
вт, 3 июля 2018 г. в 3:37, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>:

> On Mon, Jul 2, 2018 at 4:33 PM, Andrey <parihaaraka(at)gmail(dot)com> wrote:
>
>> PostgreSQL 9.6.9, 10.4 (broken):
>> A: listen test;
>> A: select pg_sleep(5);
>> 1
>> 2
>> B: notify test, 'test1';
>> 3
>> 4
>> 5
>> A: done
>> 6
>> 7
>> 8
>> 9
>> B: notify test, 'test2';
>> A:
>> * notification received:
>> server process id: 2837
>> channel: test
>> payload: test
>> * notification received:
>> server process id: 2837
>> channel: test
>> payload: test2
>>
>> PostgreSQL 9.6.2 and earlier (workds as expected)
>> A: listen test;
>> A: select pg_sleep(5);
>> 1
>> 2
>> B: notify test, 'test1';
>> 3
>> 4
>> 5
>> A: done
>> A:
>> * notification received:
>> server process id: 2837
>> channel: test
>> payload: test
>> 6
>> 7
>> 8
>> 9
>> B: notify test, 'test2';
>> A:
>> * notification received:
>> server process id: 2837
>> channel: test
>> payload: test2
>>
>
> 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.
>
> Cheers,
>
> Jeff
>