Re: Enabling Checksums

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>

To: Simon Riggs <simon@2ndQuadrant.com>

Cc: Ants Aasma <ants@cybertec.at>, Florian Pflug <fgp@phlo.org>, Robert Haas <robertmhaas@gmail.com>, Greg Smith <greg@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Heikki Linnakangas <hlinnakangas@vmware.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>

Date: 2013-04-24T20:06:57Z

Lists: pgsql-hackers

On Wed, 2013-04-24 at 08:20 +0100, Simon Riggs wrote:
> On 24 April 2013 01:10, Jeff Davis <pgsql@j-davis.com> wrote:
> > I'd prefer that it was some kind of a checksum ID code -- e.g. 0 for no
> > checksum, 1 for FNV-1a-SR3, etc. That would allow us to release 9.4 with
> > a new algorithm without forcing existing users to change.
> 
> That's exactly what the patch does.

The word "version" indicates an order to it though, like N+1 is always
preferable to N. This is user-facing (through pg_controldata output),
otherwise I wouldn't mind.

> > initdb would have to take the code as an option, probably in string
> > form.
> 
> When/if we have multiple options we can add that. The main thing was
> to make sure the control file recorded things in a common way.

The main strange thing to me is that we're still using the
enabled/disabled for the output of pg_controldata as well as the
"version".

When we do have multiple options, it seems like we'd just have one field
output:

  Data page checksums: none|crc32c|pg-fnv

What goal are you trying to accomplish with this patch? pg_control
doesn't need to be compatible between releases, so can't we just add
this later when we really do have multiple options?

Regards,
	Jeff Davis