Re: [HACKERS] postmaster disappears
От | Tatsuo Ishii |
---|---|
Тема | Re: [HACKERS] postmaster disappears |
Дата | |
Msg-id | 199909211527.AAA01357@srapc451.sra.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] postmaster disappears (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] postmaster disappears
|
Список | pgsql-hackers |
>Tatsuo Ishii <t-ishii@sra.co.jp> writes: >> In this case errno=ECHILD has been returned that makes postmaster >> exiting. This could happen if SIGCHLD raised between select() call and >> the next if (errno=...) statement. One of the solution would be >> ignoring ECHILD as well as EINTR. Included are patches for this. > >Hmm. What you are saying, I guess, is that SIGCHLD is raised, >reaper() executes, and then when control continues in the main loop >the errno left over from reaper()'s last kernel call is what's seen, >instead of the one returned by signal(). Right. >Seems to me that the correct fix is to have reaper() save and restore >the outer value of errno, not to hack the main line to ignore the >most probable state left over from reaper(). Otherwise you still choke >if some other value gets returned from whatever call reaper() does >last. Not sure. reaper() may be called while reaper() is executing if a new SIGCHLD is raised. How do you handle this case? >Moreover, you're not actually checking what the select() did unless >you do it that way. Sorry, I don't understand this. Can you explain, please? >Curious that this sort of problem is not seen more often --- I wonder >if most Unixes arrange to save/restore errno around a signal handler >for you? Maybe because the situation I have pointed out is relatively rare. --- Tatsuo Ishii
В списке pgsql-hackers по дате отправления: