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