Horton

Re: Windows buildfarm members vs. new async-notify isolation test

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Mark Dilger <hornschnorter@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-12-07T17:20:51Z
Lists: pgsql-hackers 
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?
Since only some of our Windows critters are showing it, it's evidently
dependent on environment or Windows version somehow.

			regards, tom lane

Commits

  1. Use only one thread to handle incoming signals on Windows.

  2. Fix race condition in our Windows signal emulation.