Re: NOTIFY does not work as expected

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

Hello. I beg your pardon, but the problem is still in 10.5. May we expect it to be fixed in 11?
Thanks.