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

At 2026-08-17 17:07:26, "Daniel Gustafsson" <daniel(at)yesql(dot)se> wrote:
> On 17 Aug 2026, at 10:36, Yilin Zhang <jiezhilove(at)126(dot)com> wrote:
> > For regression‑test scenarios simulating the "exactly‑one‑page‑failure‑per‑file" fault, there is a blind spot in the counter.
> > The final ERROR on total_checksum_failures in basebackup.c will still abort the backup, but this check can become ineffective.
> I might be missing what you are referring to, isn't the check for the backup
> command not failing catching this?

In the "exactly‑one‑corrupted‑page‑per‑file" scenario, the backup fails.
The failure is triggered at the end of perform_base_backup() when total_checksum_failures equals 1,
via ereport(ERROR, errcode(XX001)).
However, pg_stat_database.checksum_failures is not updated at all.

Failure cases that can be captured by pg_stat_database.checksum_failures (≥2 corrupted pages per file) invariably result in backup failure:
total_checksum_failures becomes greater than zero and triggers an unconditional ERROR.
Judging by the current test cases,,
pg_stat_database.checksum_failures appears to offer no detection capability beyond what ok($backup->finish) already provides.

> > In this scenario, if a user starts a backup a few seconds before enable completes, the entire backup skips all page checksums.
> > Users will obtain a backup with zero checksum validation, while believing checksum verification is enabled.
> There is little we can do though isn't there? If a backup completes seconds
> before inserting very important data then that data isn't backed up, we cannot
> foresee what the user might do and we cannot foresee a checksum enabling
> finishing in time so we should wait. The effects on verification during a
> backup should however be documented.
> --
> Daniel Gustafsson

Yes, either a warning or a documentation note would be fine.

Best regards,

--

Yilin Zhang