| From: | Aleksander Alekseev <aleksander(at)timescale(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
| Subject: | Re: better page-level checksums |
| Date: | 2022-06-13 13:23:18 |
| Message-ID: | CAJ7c6TNucR2fVuWzfnYb8WZrCmRBaDUXqc=wi5qx0iHnw2RZBg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi hackers,
> > 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.
That's very interesting, Andrey. Thanks for sharing.
> One of my questions is what algorithm(s) we'd want to support.
Should it necessarily be a fixed list? Why not support plugable algorithms?
An extension implementing a checksum algorithm is going to need:
- several hooks: check_page_after_reading, calc_checksum_before_writing
- register_checksum()/deregister_checksum()
- an API to save the checksums to a seperate fork
By knowing the block number and the hash size the extension knows
exactly where to look for the checksum in the fork.
--
Best regards,
Aleksander Alekseev
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nitin Jadhav | 2022-06-13 13:38:35 | Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs) |
| Previous Message | Amit Kapila | 2022-06-13 12:26:33 | Re: Replica Identity check of partition table on subscriber |