Re: Windows buildfarm members vs. new async-notify isolation test
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
Mark Dilger <hornschnorter@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-12-08T05:15:36Z
Lists: pgsql-hackers
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
Commits
-
Use only one thread to handle incoming signals on Windows.
- 16114f2ea0c0 13.0 landed
-
Fix race condition in our Windows signal emulation.
- df44e411c008 9.6.17 landed
- 7309e75fa956 9.4.26 landed
- 1a0c65120137 9.5.21 landed
- 096ea540e1e9 10.12 landed
- 2ed302ab9703 11.7 landed
- 28e6a2fd6358 13.0 landed
- 001362cfdc94 12.2 landed