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+hUKGJrcSLBmh8PsFYN5_-x73ZWEBU7eM694A=g_OxczsmTdw@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)  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Thu, Sep 24, 2020 at 2:39 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> Does this patch work fine with warm-standby case using pg_standby?
> IIUC the startup process doesn't call WaitLatch() in that case, so ISTM that,
> with the patch, it cannot detect the postmaster death immediately.

Right, RestoreArchivedFile() uses system(), so I guess it can hang
around for a long time after unexpected postmaster exit on every OS if
the command waits.  To respond to various kinds of important
interrupts, I suppose that'd ideally use something like
OpenPipeStream() and a typical WaitLatch() loop with CFI().  I'm not
sure what our policy is or should be for exiting while we have running
subprocesses.  I guess that is a separate issue.

Here's a rebase, no code change.

Attachment

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: problem with RETURNING and update row movement
Next
From: Michael Paquier
Date:
Subject: Re: Add information to rm_redo_error_callback()