Re: Question about UpdateFullPageWrites() at the end of recovery.

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Question about UpdateFullPageWrites() at the end of recovery.
Date: 2025-02-12 13:37:04
Message-ID: 1459046d-32e4-468c-bfff-d6223eef2dcd@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025/02/08 8:44, Masahiko Sawada wrote:
> Hi,
>
> I have a question about the comment of UpdateFullPageWrites() called
> at the end of recovery (in StartupXLOG()):
>
> /*
> * Update full_page_writes in shared memory and write an XLOG_FPW_CHANGE
> * record before resource manager writes cleanup WAL records or checkpoint
> * record is written.
> */
> Insert->fullPageWrites = lastFullPageWrites;
> UpdateFullPageWrites();
>
> The comment says that it expects to write an XLOG_FPW_CHANGE record
> there but that record is not actually written as it's still in
> recovery (i.e., RecoveryInProgress() still returns true). Which seems
> inconsistent.
>
> Even if we replay XLOG_FPW_CHANGE during the recovery, we just change
> the lastFullPageWrites, and at the end of the recovery, we anyway set
> the value of full_page_writes in the config file to
> Insert->fullPageWrites before accepting writes. Also, the
> full-page-write state on the standby doesn't affect taking backups on
> standby as we forcibly enable full-page-writes during taking a backup.
> So I thought it would not be a problem even if we don't write
> XLOG_FPW_CHANGE there, but I might be missing something.

Please imagine the case where full_page_writes is disabled on a standby
during recovery, that standby is promoted to a new primary,
this new primary generates WAL with full_page_writes disabled.

The issue seems that, since no FPW CHANGE record is written in this case,
another standby replicating from this new primary won’t detect the change
in full_page_writes. This means taking a base backup from that downstream
standby could complete successfully, even though the WAL data might be
generated with full_page_writes disabled.

Isn't this an unexpected and potentially problematic behavior?

> Should we revise the comment? or change the code so it can write that record?

If my analysis is correct, ISTM that the code should be updated to write
an FPW CHANGE record at the end of recovery.

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2025-02-12 13:46:06 Re: [PATCH] Optionally record Plan IDs to track plan changes for a query
Previous Message John Naylor 2025-02-12 13:06:35 Re: Improve CRC32C performance on SSE4.2