Re: [HACKERS] postmaster disappears

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] postmaster disappears
Date: 1999-09-21 15:27:55
Message-ID: 199909211527.AAA01357@srapc451.sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 1999-09-21 15:28:51 Re: [HACKERS] Re: Referential Integrity In PostgreSQL
Previous Message Thomas Lockhart 1999-09-21 15:21:31 Re: [HACKERS] Re: HISTORY for 6.5.2]