Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)

On 09/04/2021 07:01, Thomas Munro wrote:
> On Wed, Mar 31, 2021 at 7:02 PM Thomas Munro <thomas.munro@gmail.com> wrote:
>> 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.
> 
> Alright, here's a proof-of-concept patch that does that.  Adding to the next CF.

Looks good to me.

> This seems to work on Linux, macOS, FreeBSD and OpenBSD (and I assume
> any other BSD).  Can anyone tell me if it works on illumos, AIX or
> HPUX, and if not, how to fix it or disable the feature gracefully?
> For now the patch assumes that if you have SIGIO then you can do this;
> perhaps it should also test for O_ASYNC?  Perhaps HPUX has the signal
> but requires a different incantation with I_SETSIG?

I think it would be OK to just commit this (after REL_14_STABLE has been 
created) and see what breaks in the buildfarm. Then we'll at least know 
if we need more autoconf checks or something to disable this.

- Heikki