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: Tue, 10 Dec 2019 10:57:13 -0500
Message-ID: <7254.1575993433@sss.pgh.pa.us> (raw)
In-Reply-To: <CAA4eK1Ko-jYO-6FtirWSixd63D_oLyT1KL5srnjXEKMg5QoiNA@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>
<30330.1575739251@sss.pgh.pa.us>
<4412.1575748586@sss.pgh.pa.us>
<9110.1575824266@sss.pgh.pa.us>
<CAA4eK1Ko-jYO-6FtirWSixd63D_oLyT1KL5srnjXEKMg5QoiNA@mail.gmail.com>
Amit Kapila <amit.kapila16@gmail.com> writes:
> On Sun, Dec 8, 2019 at 10:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?
> Right, the client is engaged in a CallNamedPipe operation, but the
> current mechanism can allow multiple such clients and that might lead
> to faster processing of signals.
It would only matter if multiple processes signal the same backend at the
same time, which seems to me to be probably a very minority use-case.
For the normal case of one signal arriving at a time, what I'm suggesting
ought to be noticeably faster because of fewer kernel calls. Surely
creating a new pipe instance and a new thread are not free.
In any case, the main thing I'm on about here is getting rid of the
failure modes. The existing code does have a rather lame/buggy
workaround for the cant-create-new-pipe case. A possible answer for
cant-create-new-thread might be to go ahead and service the current
request locally in the long-lived signal thread. But that seems like
it's piling useless (and hard to test) complexity on top of useless
complexity.
> Ideally, we can run a couple of tests to see if there is any help in
> servicing the signals with this mechanism over proposed change on
> different Windows machines, but is it really worth the effort?
The failure modes I'm worried about are obviously pretty low-probability;
if they were not, we'd be getting field reports about it. So I'm not
sure how you can test your way to a conclusion about whether this is an
improvement. But we're not in the business of ignoring failure modes
just because they're low-probability. I'd argue that a kernel call
that's not there is a kernel call that cannot fail, and therefore ipso
facto an improvement.
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: <7254.1575993433@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