On Sat, Dec 7, 2019 at 10:50 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapil...@gmail.com> writes: > > On Sat, Dec 7, 2019 at 5:01 AM Tom Lane <t...@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
