| From: | Markus Wanner <markus(at)bluegap(dot)ch> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Jesper Krogh <jesper(at)krogh(dot)cc>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Enabling Checksums |
| Date: | 2012-11-12 08:44:23 |
| Message-ID: | 50A0B6E7.6060502@bluegap.ch |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jeff,
On 11/10/2012 12:08 AM, Jeff Davis wrote:
> The bit indicating that a checksum is present may be lost due to
> corruption.
Hm.. I see.
Sorry if that has been discussed before, but can't we do without that
bit at all? It adds a checksum switch to each page, where we just agreed
we don't event want a per-database switch.
Can we simply write a progress indicator to pg_control or someplace
saying that all pages up to X of relation Y are supposed to have valid
checksums?
That would mean having to re-calculate the checksums on pages that got
dirtied before VACUUM came along to migrate them to having a checksum,
but that seems acceptable. VACUUM could even detect that case and
wouldn't have to re-write it with the same contents.
I realize this doesn't support Jesper's use case of wanting to have the
checksums only for newly dirtied pages. However, I'd argue that
prolonging the migration to spread the load would allow even big shops
to go through this without much of an impact on performance.
Regards
Markus Wanner
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Markus Wanner | 2012-11-12 09:26:11 | Re: Enabling Checksums |
| Previous Message | Heikki Linnakangas | 2012-11-12 08:22:59 | Re: Inadequate thought about buffer locking during hot standby replay |