Horton

Re: NOTIFY does not work as expected

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrey <parihaaraka@gmail.com>, Pg Bugs <pgsql-bugs@postgresql.org>
Date: 2018-07-04T18:30:55Z
Lists: pgsql-bugs 
Hi,


On 2018-07-04 08:50:12 -0400, Jeff Janes wrote:
> Reading through the comments touched by the commit, it seems obvious what
> the bug is.  It says "cause the processing to occur just before we next go
> idle", but also says "This is called just *after* waiting for a frontend
> command", which is too late to be "before we next go idle"

I've not looked at this issue in depth yet. So I might be completely off
base.  But I'm confused by your comment - we're doing it *after*,
because we do a non-blocking read. And the latch will notify us
(event.events & WL_LATCH_SET) if there was a read.

Are you arguing that we should also notify in cases where we actually
never become idle? I'm not sure that's particularly meaningful, given
there's no guarantee that that actually works, because we could just
have read multiple commands from the client?

Greetings,

Andres Freund

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.