Re: [HACKERS] PATCH: Keep one postmaster monitoring pipe per process
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Marco Pfatschbacher <Marco_Pfatschbacher@genua.de>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2018-04-11T00:26:43Z
Lists: pgsql-hackers
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
Commits
-
Add WL_EXIT_ON_PM_DEATH pseudo-event.
- cfdf4dc4fc96 12.0 landed
-
Use signals for postmaster death on Linux.
- 9f09529952ac 12.0 landed