Re: 16-bit page checksums for 9.2
От | Bruce Momjian |
---|---|
Тема | Re: 16-bit page checksums for 9.2 |
Дата | |
Msg-id | 20120205022056.GA1307@momjian.us обсуждение исходный текст |
Ответ на | Re: 16-bit page checksums for 9.2 (Martijn van Oosterhout <kleptog@svana.org>) |
Список | 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@anarazel.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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: