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
