From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Magnus Hagander <magnus@hagander.net>
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: Mon, 9 Dec 2019 13:24:53 -0500
Message-ID: <b52b48e8-bff0-c3bb-19ed-068e8598ff6a@2ndQuadrant.com> (raw)
In-Reply-To: <9110.1575824266@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>
<4412.1575748586@sss.pgh.pa.us>
<9110.1575824266@sss.pgh.pa.us>
On 12/8/19 11:57 AM, Tom Lane wrote:
> I wrote:
>> 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.
> Here's a possible patch (untested by me) to get rid of the second thread
> and the new-pipe-for-every-request behavior. I believe that the existing
> logic may be based on Microsoft's "Multithreaded Pipe Server" example [1]
> or something similar, but that's based on an assumption that servicing
> a client request may take a substantial amount of time and it's worth
> handling requests concurrently. Neither point applies in this context.
>
> Doing it like this seems attractive to me because it gets rid of two
> different failure modes: inability to create a new thread and inability
> to create a new pipe handle. Now on the other hand, it means that
> inability to complete the read/write transaction with a client right
> away will delay processing of other signals. But we know that the
> client is engaged in a CallNamedPipe operation, so how realistic is
> that concern?
>
> This is to be applied on top of the other patch I just sent.
>
> regards, tom lane
>
> [1] https://docs.microsoft.com/en-us/windows/win32/ipc/multithreaded-pipe-server
Patch 1 fixed the problems on frogmouth.
Patch 2 also ran without incident.
tests run on REL_10_STABLE
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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: andrew.dunstan@2ndquadrant.com, tgl@sss.pgh.pa.us, amit.kapila16@gmail.com, magnus@hagander.net, hornschnorter@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Windows buildfarm members vs. new async-notify isolation test
In-Reply-To: <b52b48e8-bff0-c3bb-19ed-068e8598ff6a@2ndQuadrant.com>
* 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