Re: Enabling Checksums

On 11 April 2013 04:27, Jeff Davis <pgsql(at)j-davis(dot)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