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: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrey <parihaaraka@gmail.com>, Pg Bugs <pgsql-bugs@postgresql.org>
Date: 2018-07-04T22:11:03Z
Lists: pgsql-bugs 
On Wed, Jul 4, 2018 at 2:30 PM, Andres Freund <andres@anarazel.de> wrote:

> 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.
>

We get a signal while we are busy.  We set the flag and the latch.  The
latch
wakes us up, but since we are busy (in a transaction, specifically) we don't
do anything.  Later, the transaction ends and we are about to go idle, but
no one checks the flag again.  We start a read using the latch mechanism,
but
the flag notifyInterruptPending being set true from a now-long-gone signal
is not on
the list of things the latch wakes us for.  It is technically a
non-blocking read but from
the perspective if the pending notify message it is a blocking read, unless
another
signal comes along and rescues us.

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.