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
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 |