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>
Subject: Re: Windows buildfarm members vs. new async-notify isolation test
In-reply-to: 
 <CAA4eK1LRwxr51JuXsgpmCA+-uswCHiGvhZ88jPz8VeJxfyv65g@mail.gmail.com>
References: <32745.1575303812@sss.pgh.pa.us>
 <7221b3b4-fc7f-404d-5cf6-830d3aa6800d@2ndQuadrant.com>
 <362bca0b-1c1c-c760-ab19-b5d9a14c69ea@gmail.com>
 <13003.1575391248@sss.pgh.pa.us>
 <CAA4eK1+qevZ=sB1nW05_gkiHLWjUU0psNPiutFnQi=+aCztLXA@mail.gmail.com>
 <25746.1575436347@sss.pgh.pa.us>
 <CAA8=A78X-0vVd5tk7r=Z7yEWW5Vy1=46q7wjZaOa8Xaed5FooQ@mail.gmail.com>
 <CAA4eK1+HOFzs=-MHDz6ef936KuuHJBxZbHEi7xt9TBqgHNO9GQ@mail.gmail.com>
 <e1eb7182-a487-42f1-e113-4e5758e8ceef@2ndQuadrant.com>
 <20102.1575675105@sss.pgh.pa.us>
 <CAA4eK1LRwxr51JuXsgpmCA+-uswCHiGvhZ88jPz8VeJxfyv65g@mail.gmail.com>
Comments: In-reply-to Amit Kapila <amit.kapila16@gmail.com>
	message dated "Sat, 07 Dec 2019 09:38:58 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <30329.1575739251.1@sss.pgh.pa.us>
Date: Sat, 07 Dec 2019 12:20:51 -0500
Message-ID: <30330.1575739251@sss.pgh.pa.us>
Precedence: bulk

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