Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds) - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)
Date
Msg-id CA+hUKGJiejg=GPTkf3S53N0-Vr4fOQ4wev7DmAVVLHbh=O9+dg@mail.gmail.com
Whole thread Raw
In response to Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Fri, Mar 12, 2021 at 7:55 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Thu, Mar 11, 2021 at 7:34 PM Michael Paquier <michael@paquier.xyz> wrote:
> > Wow.  This probably means that we would be able to get rid of
> > USE_POSTMASTER_DEATH_SIGNAL?
>
> We'll still need it, because there'd still be systems with no signal:
> NetBSD, OpenBSD, AIX, HPUX, illumos.

Erm, and of course macOS.

There is actually something we could do here: ioctl(I_SETSIG) for
SysV-derived systems and fcntl(O_ASYNC) for BSD-derived systems seems
like a promising way to get a SIGIO signal when the postmaster goes
away and the pipe becomes readable.  Previously I'd discounted this,
because it's not in POSIX and I doubted it would work well on other
systems.  But I was flicking through Stevens' UNIX book while trying
to figure out that POLLHUP stuff from a nearby thread (though it's
useless for that purpose) and I learned from section 12.6 that SIGIO
is fairly ancient, originating in 4.2BSD, adopted by SVR4, so it's
likely present in quite a few systems, maybe even all of our support
platforms if we're prepared to do it two different ways.  Just a
thought.



pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Re: Get memory contexts of an arbitrary backend process
Next
From: vignesh C
Date:
Subject: Re: Replication slot stats misgivings