| From: | Adam Lee <adam8157(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Fix minRecoveryPoint not advanced past checkpoint in CreateRestartPoint |
| Date: | 2026-04-08 07:05:03 |
| Message-ID: | adX97VrD4pJKF8zt@MAC-CVW1VHW5R6 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thanks for reviewing!
On Wed, Apr 08, 2026 at 11:41:32AM +0900, Michael Paquier wrote:
> TBH, I am not convinced that this optimization in the control file is
> worth it. minRecoveryPoint refers to a state where the on-disk pages
> are all consistent based on their stored LSNs, see also the
> cross-check that we do at the end of recovery in the event of
> inconsistent pages. In most cases (say in the 99%-ish range), we will
> have page flushes, making it non-relevant.
I understand your point about minRecoveryPoint being primarily about on-disk
page consistency.
However, this value is also exposed via pg_controldata and used by external
tools - for example, pg_rewind reads it to determine where to start replaying
WAL. Third-party backup/recovery tools (like the project I'm working on) may
rely on it to verify that recovery has actually reached a specific restore
point. When the value is behind the actual replay position, these tools can
draw incorrect conclusions.
> With time, I have also learnt the hard way that the less code paths
> that update minRecoveryPoint in the control file, as well as the local
> copies, the better. Simplifying this code is something we should try
> to work on. Complicating it more has less value.
Agree. Note that this patch actually removes a code path rather than adding one
- the previous lastCheckPointEndPtr update is subsumed by the GetCurrentReplayRecPtr()
call, the complexity is roughly the same in terms of code paths and logic (I think).
> If we decide that this optimization is worth having, I am going to
> request a TAP test to validate the behavior you'd expect out of it.
PATCH v3 attached, which includes a TAP test covering multiple scenarios:
shutdown with and without a preceding CHECKPOINT, as well as promote and
pause actions for completeness. The test verifies that minRecoveryPoint
reaches at least the restore point LSN in each case.
--
Adam
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Fix-minRecoveryPoint-not-advanced-past-checkpoint-in.patch | text/plain | 11.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lakshmi N | 2026-04-08 07:09:23 | DOCS: pg_plan_advice minor doc fixes |
| Previous Message | Chao Li | 2026-04-08 07:04:34 | Re: Exit walsender before confirming remote flush in logical replication |