Re: basebackup: do not verify checksums on pages written before enabling checksums

Hi,

On Sat, Aug 15, 2026 at 03:30:56PM +0100, Zsolt Parragi wrote:
> > Can we combine the two tests into a single 010_backup.pl to keep cluster
> > inits down?
>
> I reworked the tests with another injection point as part of this,
> this way they shouldn't be flaky on CI and they are significantly
> faster now.
>
> > I'm not sure that "since the server started" is enough for a backup taken from
> > a standby. XLogCtl is zeroed at startup, while the checksum state is restored
> > from pg_control. The standby can become available before replay reaches the
> > latest checksum transition, so verification could resume with
> > lastChecksumChangeRecPtr invalid.
>
> There was really an issue there, I think we can solve that by
> advancing minrecoverypoint.

Yeah, that works too. IIUC we advance minRecoveryPoint for every checksum state
record. I wonder if we could do so only when necessary, means when verification
change (inprogress-on->on and on->inprogress-off). That said that's a nit as
advancing it for every transition is simpler and less error prone.

=== 1

+my $enable_start_lsn =
+ $node_primary->safe_psql('postgres', 'SELECT pg_current_wal_insert_lsn();');
bla
bla
+enable_data_checksums($node_primary);

So enable_start_lsn is recorded before enable starts.

And:

+ "SELECT '$min_recovery'::pg_lsn > '$enable_start_lsn'::pg_lsn;"),
+ 't',
+ 'minRecoveryPoint advanced past the checksum state change');

Since enabling emits both inprogress-on and on records, this would pass even if
only the first one advanced minRecoveryPoint.

If we want to check that minRecoveryPoint >= final on record, could the test use
datachecksums-enable-checksums-delay to pause before that transition and establish
the restartpoint there?

=== 2

+# A backup started once enabling has completed must verify, and pass
+$node->command_ok(
+ [
+ 'pg_basebackup', '-D', $node->backup_dir . '/after_enable',
+ '--wal-method=none', '--no-sync', '--checkpoint=fast'
+ ],
+ 'backup after enable completion succeeds');

I think that only prove that no false checksum failure is reported.
Could one post transition backup reuse the existing corruption mechanism (see
010_pg_basebackup.pl) to check that verification resumes?

=== 3

011_standby_straddle.pl does:

+bgwriter_lru_maxpages = 0

but 010_backup_straddle.pl does not. Should 010_backup_straddle.pl also disable
bgwriter to preserve dirty pages?

Regards,

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