On Sat, Dec 7, 2019 at 10:50 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Amit Kapila <amit.kapila16@gmail.com> writes:
> > On Sat, Dec 7, 2019 at 5:01 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> 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.
>
> There are fewer processes involved in that case, so I don't think
> it disproves the theory that this is a scheduler glitch.
>
> > 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.
>
> Have you done that debugging on a machine that's showing the failure?
>
No, it is on my local Win-7 setup.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com