Re: Offline data checksum changes can cause incorrect checksum state on standbys

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