At 2026-08-17 17:07:26, "Daniel Gustafsson" <[email protected]> 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
