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

Hi,

On Tue, Sep 01, 2026 at 12:31:42AM +0100, Zsolt Parragi wrote:
> > I found a case where the source's online enable occurs after divergence and was
> > never seen by the target, but replay skips it instead of applying it:
> > ....
> > Maybe the watermark needs timeline context, or pg_rewind needs to adjust it
> > when it comes from the target's divergent history?
>
> Thanks! v8 adds the latter, with a new test case verifying this scenario.

Thanks!

As far the new test:

=== 1

+# Clean switchover back to A; enable checksums online on it.
+$node_b->stop('fast');
+$node_a->promote;

IIUC, the preceding wait_for_catchup() does not cover the shutdown checkpoint
written by stop(). Therefore, the divergence checkpoint in scenario 2 is not
guaranteed to carry off, as described.

=== 2

+enable_data_checksums($node_b, wait => 'on');
+test_checksum_state($node_b, 'on');
...
+$node_a->wait_for_catchup($node_b, 'replay', $node_a->lsn('insert'));
+test_checksum_state($node_b, 'on');

The target is already "on" before pg_rewind, so the final assertion does not
prove that the source's enable record was replayed.

Please find attached a small patch addressing those two test comments to apply
on top of v8. What do you think?

=== 3

+ /*
+ * End of the newest XLOG2_CHECKSUMS record this node has written or
+ * applied.

and

+ * would skip them as already applied. Clamp it to the divergence point,
+ * so that every transition record on the source's history takes effect.
+ */
+ if (ControlFile_new.data_checksum_lsn > divergerec)
+ ControlFile_new.data_checksum_lsn = divergerec;

divergerec is not necessarily the end of an XLOG2_CHECKSUMS record, so the
comment no longer describes every value the field may contain. Maybe it should
describe it as the WAL position through which checksum transitions are covered?

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com