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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)
Дата
Msg-id 20201116075606.GA19692@paquier.xyz
обсуждение исходный текст
Ответ на Re: PostmasterIsAlive() in recovery (non-USE_POST_MASTER_DEATH_SIGNAL builds)  (Thomas Munro <thomas.munro@gmail.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Drouvot, Bertrand"
Дата:
Сообщение: Re: Add Information during standby recovery conflicts
Следующее
От: "Shinoda, Noriyoshi (PN Japan FSI)"
Дата:
Сообщение: Tab complete for CREATE OR REPLACE TRIGGER statement