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
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] |