From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Mark Dilger <hornschnorter@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Windows buildfarm members vs. new async-notify isolation test
Date: Sat, 07 Dec 2019 14:56:26 -0500
Message-ID: <4412.1575748586@sss.pgh.pa.us> (raw)
In-Reply-To: <30330.1575739251@sss.pgh.pa.us>
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>
<30330.1575739251@sss.pgh.pa.us>
I 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.
So, just idly looking at the code in src/backend/port/win32/signal.c
and src/port/kill.c, I have to wonder why we have this baroque-looking
design of using *two* signal management threads. And, if I'm
reading it right, we create an entire new pipe object and an entire
new instance of the second thread for each incoming signal. Plus, the
signal senders use CallNamedPipe (hence, underneath, TransactNamedPipe)
which means they in effect wait for the recipient's signal-handling
thread to ack receipt of the signal. Maybe there's a good reason for
all this but it sure seems like a lot of wasted cycles from here.
I have to wonder why we don't have a single named pipe that lasts as
long as the recipient process does, and a signal sender just writes
one byte to it, and considers the signal delivered if it is able to
do that. The "message" semantics seem like overkill for that.
I dug around in the contemporaneous archives and could only find
https://www.postgresql.org/message-id/303E00EBDD07B943924382E153890E5434AA47%40cuthbert.rcsinc.local
which describes the existing approach but fails to explain why we
should do it like that.
This might or might not have much to do with the immediate problem,
but I can't help wondering if there's some race-condition-ish behavior
in there that's contributing to what we're seeing. We already had to
fix a couple of race conditions from doing it like this, cf commits
2e371183e, 04a4413c2, f27a4696f. Perhaps 0ea1f2a3a is relevant
as well.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, amit.kapila16@gmail.com, magnus@hagander.net, andrew.dunstan@2ndquadrant.com, hornschnorter@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Windows buildfarm members vs. new async-notify isolation test
In-Reply-To: <4412.1575748586@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox