Hi, On 2018-04-11 12:17:14 +1200, Thomas Munro wrote: > I arrived at this idea via the realisation that the closest thing to > prctl(PR_SET_PDEATHSIG) on BSD-family systems today is > please-tell-my-kqueue-if-this-process-dies. It so happens that my > kqueue patch already uses that instead of the pipe to detect > postmaster death. The only problem is that you have to ask it, by > calling it kevent(). In a busy loop like those two, where there is no > other kind of waiting going on, you could do that by calling kevent() > with timeout = 0 to check the queue.
Which is not cheap. > You could probably figure out a way to hide the > prctl(PR_SET_PDEATHSIG)-based approach inside the WaitEventSet code, > with a fast path that doesn't make any system calls if the only event > registered is postmaster death (you can just check the global variable > set by your signal handler). But I guess you wouldn't like the extra > function call so I guess you'd prefer to check the global variable > directly in the busy loop, in builds that have > prctl(PR_SET_PDEATHSIG). Yea, I'd really want this to be a inline function of the style static inline bool PostmasterIsAlive(void) { if (!postmaster_possibly_dead) return true; return PostmasterIsAliveInternal(); } I do not like the WES alternative because a special cased "just postmaster death" WES seems to have absolutely no advantage over a faster PostmasterIsAlive(). And using WES seems to make a cheap check like the above significantly more complicated. Greetings, Andres Freund