From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Question about UpdateFullPageWrites() at the end of recovery. |
Date: | 2025-02-07 23:44:27 |
Message-ID: | CAD21AoDHPFZrbbyKN3byLgqRJcONh3qu5Pn=uqOfDUH62Dp2Rw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Should we revise the comment? or change the code so it can write that record?
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2025-02-07 23:54:40 | Re: Adjusting hash join memory limit to handle batch explosion |
Previous Message | Tomas Vondra | 2025-02-07 23:29:11 | Re: should we have a fast-path planning for OLTP starjoins? |