Re: RecoveryInProgress() has critical side effects

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: "Bossart, Nathan" <bossartn(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, amul sul <sulamul(at)gmail(dot)com>
Subject: Re: RecoveryInProgress() has critical side effects
Date: 2021-12-13 15:10:43
Message-ID: CA+TgmoYm50JNL-h1yahw5UHhgZmtjx35O31SC-tCJQsTQFwEBA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 7, 2021 at 5:55 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Sat, Dec 4, 2021 at 7:44 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> > My main worry here is that this changes slightly the definition of
> > doPageWrites across stable branches at the end of recovery as there
> > could be records generated there. Note that GetFullPageWriteInfo()
> > gets called in XLogInsert(), while Insert->fullPageWrites gets updated
> > before CleanupAfterArchiveRecovery(). And it may influence
> > the value of doPageWrites in the startup process.
>
> But ... so what? All the code that uses it retries if the value that
> was tentatively used turns out to be wrong.

Despite the fact that this question didn't get further discussion, and
the fact that nobody seems quite sure what the best way of proceeding
here is, my interpretation of the comments made so far is that nobody
thinks that what we have now is superior to either of the proposed
alternatives, and there's a weak preference for v2 over v1. So I
committed that one.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Shruthi Gowda 2021-12-13 15:13:32 Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)
Previous Message Andrew Dunstan 2021-12-13 15:05:35 Re: daitch_mokotoff module