On Sat, Dec 7, 2019 at 5:01 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> > On 12/5/19 4:37 AM, Amit Kapila wrote:
> >> IIUC, this means that commit (step l2commit) is finishing before the
> >> notify signal is reached that session. If so, can we at least confirm
> >> that by adding something like select pg_sleep(1) in that step? So,
> >> l2commit will be: step "l2commit" { SELECT pg_sleep(1); COMMIT; }. I
> >> think we can try by increasing sleep time as well to confirm the
> >> behavior if required.
>
> > Yeah, with the sleep in there the NOTIFY is seen.
>
> Well, that is *really* interesting, because I was fairly sure that
> everything was adequately interlocked. The signal must have been
> sent before step notify1 finishes, and then we do several other
> things, so how could the listener2 process not have gotten it by
> the time we run the l2commit step? I still think this is showing
> us some sort of deficiency in our Windows signal mechanism.
>
> A possible theory as to what's happening is that the kernel scheduler
> is discriminating against listener2's signal management thread(s)
> and not running them until everything else goes idle for a moment.
>
If we have to believe that theory then why the other similar test is
not showing the problem. The other test, I am talking about is below:
# Cross-backend notification delivery.
permutation "llisten" "notify1" "notify2" "notify3" "notifyf" "lcheck"
In this test also, one session is listening and the other session sent
a few notifications and then when the first session executes another
command (lcheck), it receives the notifications. I have also debugged
it in the Windows box that as soon as the notify sends the signal, the
signal thread receives it and comes out of ConnectNamedPipe and does
the processing to dispatch the signal.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com