From: | Andrey Borodin <x4m(at)double(dot)cloud> |
---|---|
To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: better page-level checksums |
Date: | 2022-06-10 08:21:43 |
Message-ID: | CACaEdVjGXDRfUgZTy=7FEifpRfXtWUgeSWfeLgxZ0do5UeBxvA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 10, 2022 at 5:00 AM Matthias van de Meent <
boekewurm+postgres(at)gmail(dot)com> wrote:
>
> Can't we add some extra fork that stores this extra per-page
> information, and contains this extra metadata
>
+1 for this approach. I had observed some painful corruption cases where
block storage simply returned stale version of a rage of blocks. This is
only possible because checksum is stored on the page itself.
A special fork for checksums would allow us to better detect failures in
SSD firmawares, MMU SEUs etc, OS page cache, backup software and storage.
It may seems that these kind of stuff never happen. But probability of such
failure is drastically bigger than probability of hardware failure being
undetected due to CRC16 collision.
Also I'm skeptical about correcting detected errors with the information
from checksum. This approach requires very very large checksum. It's much
easier to obtain fresh block copy from HA standby.
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2022-06-10 08:39:04 | Re: Handle infinite recursion in logical replication setup |
Previous Message | Etsuro Fujita | 2022-06-10 08:17:22 | Re: Error from the foreign RDBMS on a foreign table I have no privilege on |