Re: RecoveryInProgress() has critical side effects

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
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-05 00:44:16
Message-ID: YawLYK/xuV3SxXIb@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 16, 2021 at 09:41:58AM -0500, Robert Haas wrote:
> Maybe I'm not understanding you properly here, but it seems like you
> might be forgetting that this is a local variable and thus every
> backend is going to have something different. In the startup process,
> it will be initialized by StartupXLOG(); in other processes, it's
> currently initialized by RecoveryInProgress(), but with this patch it
> wouldn't be. Either way, it's then updated by future calls to
> XLogInsertRecord() as required. XLOG_FPW_CHANGE records might affect
> the new value that gets set the next time XLogInsertRecord(), but they
> don't directly affect doPageWrites.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-12-05 00:49:45 Re: Remove extra Logging_collector check before calling SysLogger_Start()
Previous Message Chapman Flack 2021-12-04 18:31:45 Re: SPI TupTable memory context