>> Hi all,
>>
>> Was just discussing the issues related to the above off list
>with Magnus:
>>
>http://archives.postgresql.org/pgsql-hackers->win32/2004-03/msg00041.ph
p
>>
>> Whilst we can think of a number of work-arounds (the simplest being a
>> suggestion by Magnus: set a flag, like APCcalled, to false before the
>> select() call, and repeat the select() if APCcalled == true
>on return from
>> select), we were wondering if having socket calls inside
>signal handlers was
>> a good idea in any case?
>
>Is this a win32 only thing, or is it more general?
>
>OpenBSD for instance has some documentation on which functions
>are safe to be called from a signal handler, and socket
>operations aren't part of it. See for isntance their manpages
>about signal and sigaction.
This is very interesting - it points towards this being a general
problem and not just Win32. I was expecting something along this line,
since you should generally be very restrictive with what is done in a
signal handler, and socket I/O can be a lot (say it blocks, etc).
To me this sounds like we have to make a general solution, and not win32
specific, to get the socket calls out of the signal handler. This seems
to be the only one that uses it, so it should be a fairly small change.
Since in this case, it's a simple pid being sent up, it could probably
be done as simple as: (ok, not patch, just text, but..)
1) Change CleanupProc() in postmaster.c to put the pid in a list or an
array instead of calling pgstat_beterm().
2) At the select() call in ServerLoop(), poll this queue and post out
anything that has happened since last loop using pgstat_beterm().
Does this sound reasonable?
//Magnus