| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Yilin Zhang <jiezhilove(at)126(dot)com> |
| Cc: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Subject: | Re: basebackup: do not verify checksums on pages written before enabling checksums |
| Date: | 2026-08-17 09:07:26 |
| Message-ID: | E12CDBC7-80C7-440E-BD42-C698471F401D@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2026-08-17 09:15:56 | Re: Failing assertion while taking a restartpoint during crash recovery |
| Previous Message | Daniel Gustafsson | 2026-08-17 09:03:31 | Re: basebackup: do not verify checksums on pages written before enabling checksums |