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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)
Date: 2020-11-16 07:56:06
Message-ID: 20201116075606.GA19692@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 24, 2020 at 05:55:17PM +1200, Thomas Munro wrote:
> 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.

- if (IsUnderPostmaster && !PostmasterIsAlive())
+ if (IsUnderPostmaster &&
+#ifndef USE_POSTMASTER_DEATH_SIGNAL
+ count++ % 1024 == 0 &&
+#endif
+ !PostmasterIsAlive())
That's pretty hack-ish, still efficient. Could we consider a
different approach like something relying on
PostmasterIsAliveInternal() with repetitive call handling? This may
not be the only place where we care about that, particularly for
non-core code.

No objections with the two changes from pg_usleep() to WaitLatch() so
they could be applied separately first.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-11-16 08:10:05 Re: [PATCH] remove pg_archivecleanup and pg_standby
Previous Message Drouvot, Bertrand 2020-11-16 07:55:37 Re: Add Information during standby recovery conflicts