Alvaro Herrera wrote:
Blocking signal is false safe. It is race condition problem. You can receive signal before you block it, but main problem is different. See example:Zdenek Kotala wrote:I performed some investigation and I found that signal handler (SIGHUP_handler) contents a big code and contents signal nonsafe functions. It should generate deadlock or damage some internal data structure in the standard c library. See http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html for detail. By my opinion is necessary to rewrite signal handling in postmaster to avoid postgres malfunction.Perhaps you missed these lines:/* * Block all signals until we wait again. (This makes it safe for our * signal handlers to do nontrivial work.) */ PG_SETMASK(&BlockSig); postmaster.c 1227ff If you have following functions and signal handler: char buffer[11]; If you call function f1('A') you expect that content of buffer
will be "AAAAAAAAAA". It will be true until you don't receive signal.
Signal is asynchronous event and if you receive it during loop
processing (for example when n=3) then signal handler call f1 too, but
with parametr 'B'. The result in buffer will be "BBBBBBBBBB" after
signal processing. And now f1 continue with n=3, 4, 5 ... And your
expected result is "BBBAAAAAAA". That is all. For example this is
reason why you don't use functions like printf, because they content
static internal buffer. It is reason why there are only small group of
signal safe functions. Decision is that Postgres uses signal dangerous functions (fopen, ...) and its signal handler is not save and should generate unpredictable behavior after signal processing. I would like to fix it, but there is some waiting patches for this source and I don't know how to correctly (with minimal merge complication) process. Zdenek
|
- Re: [HACKERS] Bug in signal handler [Was: [TODO] Al... Zdenek Kotala
- Re: [HACKERS] Bug in signal handler [Was: [TOD... Martijn van Oosterhout
- Re: [HACKERS] Bug in signal handler Douglas McNaught
- Re: [HACKERS] Bug in signal handler Martijn van Oosterhout
- Re: [HACKERS] Bug in signal handler Tom Lane
- Re: [HACKERS] Bug in signal handle... Martijn van Oosterhout
- Re: [HACKERS] Bug in signal h... Florian Weimer