Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 24ecde7

Browse files
committed
Work around unfortunate getppid() behavior on BSD-ish systems.
On MacOS X, and apparently also on other BSD-derived systems, attaching a debugger causes getppid() to return the pid of the debugging process rather than the actual parent PID. As a result, debugging the autovacuum launcher, startup process, or WAL sender on such systems causes it to exit, because the previous coding of PostmasterIsAlive() detects postmaster death by testing whether getppid() == PostmasterPid. Work around that behavior by checking the return value of getppid() more carefully. If it's PostmasterPid, the postmaster must be alive; if it's 1, assume the postmaster is dead. If it's any other value, assume we've been debugged and fall through to the less-reliable kill() test. Review by Tom Lane.
1 parent f6a0863 commit 24ecde7

File tree

1 file changed

+21
-13
lines changed

1 file changed

+21
-13
lines changed

src/backend/storage/ipc/pmsignal.c

Lines changed: 21 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -260,22 +260,30 @@ PostmasterIsAlive(bool amDirectChild)
260260
#ifndef WIN32
261261
if (amDirectChild)
262262
{
263+
pid_t ppid = getppid();
264+
265+
/* If the postmaster is still our parent, it must be alive. */
266+
if (ppid == PostmasterPid)
267+
return true;
268+
269+
/* If the init process is our parent, postmaster must be dead. */
270+
if (ppid == 1)
271+
return false;
272+
263273
/*
264-
* If the postmaster is alive, we'll still be its child. If it's
265-
* died, we'll be reassigned as a child of the init process.
266-
*/
267-
return (getppid() == PostmasterPid);
268-
}
269-
else
270-
{
271-
/*
272-
* Use kill() to see if the postmaster is still alive. This can
273-
* sometimes give a false positive result, since the postmaster's PID
274-
* may get recycled, but it is good enough for existing uses by
275-
* indirect children.
274+
* If we get here, our parent process is neither the postmaster nor
275+
* init. This can occur on BSD and MacOS systems if a debugger has
276+
* been attached. We fall through to the less-reliable kill() method.
276277
*/
277-
return (kill(PostmasterPid, 0) == 0);
278278
}
279+
280+
/*
281+
* Use kill() to see if the postmaster is still alive. This can
282+
* sometimes give a false positive result, since the postmaster's PID
283+
* may get recycled, but it is good enough for existing uses by
284+
* indirect children and in debugging environments.
285+
*/
286+
return (kill(PostmasterPid, 0) == 0);
279287
#else /* WIN32 */
280288
return (WaitForSingleObject(PostmasterHandle, 0) == WAIT_TIMEOUT);
281289
#endif /* WIN32 */

0 commit comments

Comments
 (0)