Alvaro Herrera wrote: <blockquote cite="mid20060510201744.GA26403@surnet.cl" type="cite"><pre wrap="">Zdenek Kotala
wrote:
</pre><blockquote type="cite"><pre wrap="">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
<a class="moz-txt-link-freetext"
href="http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html">http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html</a>
for detail. By my opinion is necessary to rewrite signal handling in
postmaster to avoid postgres malfunction. </pre></blockquote><pre wrap="">
Perhaps you missed these lines:
/* * Block all signals until we wait again. (This makes it safe for our * signal handlers to do
nontrivialwork.) */ PG_SETMASK(&BlockSig);
postmaster.c 1227ff
</pre></blockquote> Blocking signal is false safe. It is race condition problem. You can receive signal before you
blockit, but main problem is different. See example:<br /><br /> If you have following functions and signal handler:<br
/><br/><code>char buffer[11];<br /><br /> void sig_handler(int signo)<br /> {<br /> f1('B');<br /> }<br /><br />
voidf1(char ch)<br /> {<br /> int n;<br /> for( n = 0 ; n < 10; n++)<br /> buffer[n] = ch; <br /> }<br
/><br/></code>If you call function f1('A') you expect that content of buffer will be "AAAAAAAAAA". It will be true
untilyou don't receive signal. Signal is asynchronous event and if you receive it during loop processing (for example
whenn=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
thisis reason why you don't use functions like printf, because they content static internal buffer. It is reason why
thereare only small group of signal safe functions. <br /><br /> 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.<br /><br /> Zdenek<br /><code><br /><br /></code><br /><br
/><br/><br /><br /><br /><br /><br />