From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: 16-bit page checksums for 9.2 |
Date: | 2012-02-05 02:20:56 |
Message-ID: | 20120205022056.GA1307@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Dec 25, 2011 at 04:25:19PM +0100, Martijn van Oosterhout wrote:
> On Sat, Dec 24, 2011 at 04:01:02PM +0000, Simon Riggs wrote:
> > On Sat, Dec 24, 2011 at 3:54 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > Why don't you use the same tricks as the former patch and copy the buffer,
> > > compute the checksum on that, and then write out that copy (you can even do
> > > both at the same time). I have a hard time believing that the additional copy
> > > is more expensive than the locking.
> >
> > ISTM we can't write and copy at the same time because the cheksum is
> > not a trailer field.
>
> Ofcourse you can. If the checksum is in the trailer field you get the
> nice property that the whole block has a constant checksum. However, if
> you store the checksum elsewhere you just need to change the checking
> algorithm to copy the checksum out, zero those bytes and run the
> checksum and compare with the extracted checksum.
>
> Not pretty, but I don't think it makes a difference in performence.
Sorry to be late replying to this, but an interesting idea would be to
zero the _hint_ bits before doing the CRC checksum. That would avoid
the problem of WAL-logging the hint bits.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-02-05 03:59:03 | Re: 16-bit page checksums for 9.2 |
Previous Message | Tom Lane | 2012-02-05 01:47:05 | Re: Review of: explain / allow collecting row counts without timing info |