Horton

Re: NOTIFY does not work as expected

Jeff Janes <jeff.janes@gmail.com>

View thread View on postgr.es
From: Jeff Janes <jeff.janes@gmail.com>
To: Andrey <parihaaraka@gmail.com>
Cc: Pg Bugs <pgsql-bugs@postgresql.org>
Date: 2018-07-03T00:37:21Z
Lists: pgsql-bugs 
On Mon, Jul 2, 2018 at 4:33 PM, Andrey <parihaaraka@gmail.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

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.