>> > > Here's a patch implementing the "thread method" to
>> > workaround the bug
>> > > with socket calls in signal handlers. See details in mail to
>> > > pgsql-hackers-win32 a couple of minutes ago.
>> >
>> > Looks ok, but wouldn't it be better placed in pgstat.c?
>>
>> Actually, I don't think so. I considered it, and chose to put it in
>> postmaster.c for the following reason:
>>
>> The functon pgstat_beterm itself is *not* the problem. In
>theory, it can
>> be called from places that are not signal handlers (sure,
>it's not done
>> today I think, but internal-API-wise, it could). That goes against
>> putting the fix ther.
>
>Sure, like I said, my 2c. Just looks a little out of place.
>Understand point
>on API, but think it is clear that this isn't a win32 replacement for
>pgstat_beterm, but a win32 replacement for pgstat_beterm *called from a
>signal handler* (perhaps a function name change would make it
>this clearer).
Could be. I think the comment makes it clear, though. But a function
rename is easy enough - have any suggestions?
>What I am wondering about now, is where else we need to change? AFAICS,
>there is (at least?) one signal handler that performs sockets
>ops, namely
>Async_NotifyHandler.
Actually, I don't think we need to do anything about that one. This
signal handler is used in the backend (not postmaster), and the backend
never calls selcet(). The other calls (recv, send etc) return correct
return values even when a socket call is made in the APC, I'm fairly
certain.
//Magnus