| From: | Robert Haas <robertmhaas(at)gmail(dot)com> | 
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com> | 
| Cc: | Markus Wanner <markus(at)bluegap(dot)ch>, Jeff Davis <pgsql(at)j-davis(dot)com>, Jesper Krogh <jesper(at)krogh(dot)cc>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Enabling Checksums | 
| Date: | 2012-11-13 20:46:25 | 
| Message-ID: | CA+TgmoYLr_H0UiFURgoWrRD5uy83OMFS_c-io_F82fDyB9FqJg@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Mon, Nov 12, 2012 at 4:44 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> That'll make it hard for VACUUM, hint-bit setting, etc to
> opportunistically checksum pages whenever they're doing a page write anyway.
>
> Is it absurd to suggest using another bitmap, like the FSM or visibility
> map, to store information on page checksumming while checksumming is
> enabled but incomplete? As a much smaller file the bitmap could its self
> be very quickly generated in one pass when checksumming is enabled, with
> its starting state showing no pages having checksums.
Hmm... what if we took this a step further and actually stored the
checksums in a separate relation fork?  That would make it pretty
simple to support enabling/disabling checksums for particular
relations.  It would also allow us to have a wider checksum, like 32
or 64 bits rather than 16.  I'm not scoffing at a 16-bit checksum,
because even that's enough to catch a very high percentage of errors,
but it wouldn't be terrible to be able to support a wider one, either.
-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-11-13 20:51:06 | Re: Memory leaks in record_out and record_send | 
| Previous Message | Christopher Browne | 2012-11-13 20:29:06 | Re: Proof of concept: standalone backend with full FE/BE protocol |