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