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

Yea, I'd really want this to be a inline function of the style

static inline bool
    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.


Andres Freund

Reply via email to