From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Mark Dilger <hornschnorter(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Windows buildfarm members vs. new async-notify isolation test |
Date: | 2019-12-09 18:24:53 |
Message-ID: | b52b48e8-bff0-c3bb-19ed-068e8598ff6a@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Karl O. Pinc | 2019-12-09 18:25:23 | Re: proposal: minscale, rtrim, btrim functions for numeric |
Previous Message | Karl O. Pinc | 2019-12-09 18:15:22 | Re: proposal: minscale, rtrim, btrim functions for numeric |