On 11 April 2013 04:27, Jeff Davis <pg...@j-davis.com> wrote: > On Wed, 2013-04-10 at 20:17 +0100, Simon Riggs wrote: > > > OK, so we have a single combined "calculate a checksum for a block" > > function. That uses Jeff's zeroing trick and Ants' bulk-oriented > > performance optimization. > > > > > > For buffer checksums we simply calculate for the block. > > Sounds good. > > > For WAL full page writes, we first set the checksums for all defined > > buffers, then calculate the checksum of remaining data plus the > > pd_checksum field from each block using the normal WAL CRC32. > > > > Seems good to me. One set of fast code. And it avoids the weirdness > > that the checksum stored on the full page is actually wrong. > > Oh, that's a nice benefit.
So, if we apply a patch like the one attached, we then end up with the WAL checksum using the page checksum as an integral part of its calculation. (There is no increase in code inside WALInsertLock, nothing at all touched in that area). Then all we need to do is make PageSetChecksumInplace() use Ants' algo and we're done. Only point worth discussing is that this change would make backup blocks be covered by a 16-bit checksum, not the CRC-32 it is now. i.e. the record header is covered by a CRC32 but the backup blocks only by 16-bit. (Attached patch is discussion only. Checking checksum in recovery isn't coded at all.) Thoughts? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
make_wal_records_use_page_checksums.v0.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
