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
