Re: NOTIFY does not work as expected

чт, 5 июл. 2018 г. в 1:11, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>:

> On Wed, Jul 4, 2018 at 2:30 PM, Andres Freund <andres(at)anarazel(dot)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.

Regards,
Andrey L