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

Commit 7bc84a1

Browse files
committed
Fix kqueue support under debugger on macOS.
While running under a debugger, macOS's getppid() can return the debugger's PID. That could cause a backend to exit because it falsely believed that the postmaster had died, since commit 815c2f0. Continue to use getppid() as a fast postmaster check after adding the postmaster's PID to a kqueue, to close a PID-reuse race, but double check that it actually exited by trying to read the pipe. The new check isn't reached in the common case. Reported-by: Alexander Korotkov <a.korotkov@postgrespro.ru> Discussion: https://postgr.es/m/CA%2BhUKGKhAxJ8V8RVwCo6zJaeVrdOG1kFBHGZOOjf6DzW_omeMA%40mail.gmail.com
1 parent e6c178b commit 7bc84a1

File tree

1 file changed

+10
-1
lines changed

1 file changed

+10
-1
lines changed

src/backend/storage/ipc/latch.c

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1094,8 +1094,17 @@ WaitEventAdjustKqueue(WaitEventSet *set, WaitEvent *event, int old_events)
10941094
errmsg("%s failed: %m",
10951095
"kevent()")));
10961096
}
1097-
else if (event->events == WL_POSTMASTER_DEATH && PostmasterPid != getppid())
1097+
else if (event->events == WL_POSTMASTER_DEATH &&
1098+
PostmasterPid != getppid() &&
1099+
!PostmasterIsAlive())
1100+
{
1101+
/*
1102+
* The extra PostmasterIsAliveInternal() check prevents false alarms on
1103+
* systems that give a different value for getppid() while being traced
1104+
* by a debugger.
1105+
*/
10981106
set->report_postmaster_not_running = true;
1107+
}
10991108
}
11001109

11011110
#endif

0 commit comments

Comments
 (0)