Hi, On Tue, Sep 01, 2026 at 02:50:04PM +0100, Zsolt Parragi wrote: > Thanks! > > I applied these changes to v9 with some additional comment editing. I > also squashed 0005 into 0001 because it describes what's implemented > there, and I also tried to significantly reduce the commit message of > 0001. Otherwise everything else is unchanged.
Thanks! I initially thought there could be two more issues: one involving a base backup spanning an online enable and another involving a crash during the first recovery after pg_rewind. Further testing showed that neither was an issue. So I'm happy with the current v9-0001 behavior. I now just have a couple of wording comments: === 1 + only then restart them. Before stopping a standby, make sure it has + replayed all WAL of its upstream node, for example by stopping the + primary first and comparing + <function>pg_last_wal_replay_lsn()</function> with + <function>pg_last_wal_receive_lsn()</function> on the standby. Equality only proves that all received WAL has been replayed, not that all upstream WAL was received. Maybe we should compare against the stopped primary's shutdown checkpoint location, as 021 does? === 2 + /* + * Mark the state as changed locally, without a WAL record. Recovery + * then knows the state is newer than anything the WAL carries and + * does not let a replayed checkpoint overwrite it. The watermark is + * left alone: any XLOG2_CHECKSUMS record this node had applied stays + * covered, and only records above it, written after this change, take + * effect again. + */ An offline change has no ordering against WAL not yet replayed, so records above the watermark may have been written before the offline change. Maybe this should be worded in terms of records covered by the watermark, without implying chronological ordering? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
