Re: [HACKERS] postmaster disappears - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: [HACKERS] postmaster disappears
Date
Msg-id 199909211527.AAA01357@srapc451.sra.co.jp
Whole thread Raw
In response to Re: [HACKERS] postmaster disappears  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] postmaster disappears  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2]
Next
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL