| From: | Jim Nasby <jim(at)nasby(dot)net> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Page Checksums |
| Date: | 2012-01-04 00:22:26 |
| Message-ID: | 68ED2664-C1E5-435E-977C-F6CD7CD72E95@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Dec 28, 2011, at 3:31 AM, Simon Riggs wrote:
> On Wed, Dec 28, 2011 at 9:00 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>> What I'm not too clear
>> about is whether a 16-bit checksum meets the needs of people who want
>> checksums.
>
> We need this now, hence the gymnastics to get it into this release.
>
> 16-bits of checksum is way better than zero bits of checksum, probably
> about a million times better (numbers taken from papers quoted earlier
> on effectiveness of checksums).
>
> The strategy I am suggesting is 16-bits now, 32/64 later.
What about allowing for an initdb option? That means that if you want binary compatibility so you can pg_upgrade then you're stuck with 16 bit checksums. If you can tolerate replicating all your data then you can get more robust checksumming.
In either case, it seems that we're quickly approaching the point where we need to start putting resources into binary page upgrading...
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Brad Davis | 2012-01-04 00:24:06 | Re: [patch] Improve documentation around FreeBSD Kernel Tuning |
| Previous Message | Tom Lane | 2012-01-04 00:11:35 | Re: Should I implement DROP INDEX CONCURRENTLY? |