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
