| From: | Stephen Frost <sfrost(at)snowman(dot)net> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
| Cc: | Jim Nasby <jim(at)nasby(dot)net>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Andres Freund <andres(at)anarazel(dot)de>, aidan(at)highrise(dot)ca, stark(at)mit(dot)edu, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: 16-bit page checksums for 9.2 |
| Date: | 2012-01-04 13:31:57 |
| Message-ID: | 20120104133157.GK24234@tamriel.snowman.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon, all,
* Simon Riggs (simon(at)2ndQuadrant(dot)com) wrote:
> (1) report all errors on a page, including errors that don't change
> PostgreSQL data. This involves checksumming long strings of zeroes,
> which the checksum algorithm can't tell apart from long strings of
> ones.
Do we actually know when/where it's supposed to be all zeros, and hence
could we check for that explicitly? If we know what it's supposed to
be, in order to be consistent with other information, I could certainly
see value in actually checking that.
I don't think that's valuable enough to go breaking abstraction layers
or bending over backwards to do it though. If we don't have the
knowledge, at the right level, that the data should all be zeros then
including those pieces in the CRC certainly makes sense to me.
Just my 2c.
Thanks,
Stephen
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2012-01-04 13:35:19 | Re: 16-bit page checksums for 9.2 |
| Previous Message | Kevin Grittner | 2012-01-04 13:31:03 | Re: 16-bit page checksums for 9.2 |