>> 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 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
