From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Kapila <amit.kapila16@gmail.com>
cc: Magnus Hagander <magnus@hagander.net>,
        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: 
 <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>
Comments: In-reply-to Amit Kapila <amit.kapila16@gmail.com>
	message dated "Tue, 10 Dec 2019 12:23:56 +0530"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7253.1575993433.1@sss.pgh.pa.us>
Date: Tue, 10 Dec 2019 10:57:13 -0500
Message-ID: <7254.1575993433@sss.pgh.pa.us>
Precedence: bulk

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