Re: Enabling Checksums

Simon Riggs <simon@2ndquadrant.com>

From: Simon Riggs <simon@2ndQuadrant.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Greg Smith <greg@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@2ndquadrant.com>, Ants Aasma <ants@cybertec.at>, Heikki Linnakangas <hlinnakangas@vmware.com>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2013-03-18T18:24:37Z
Lists: pgsql-hackers
On 18 March 2013 17:52, Bruce Momjian <bruce@momjian.us> wrote:
> On Sun, Mar 17, 2013 at 05:50:11PM -0700, Greg Smith wrote:
>> As long as the feature is off by default, so that people have to
>> turn it on to hit the biggest changed code paths, the exposure to
>> potential bugs doesn't seem too bad.  New WAL data is no fun, but
>> it's not like this hasn't happened before.
>
> With a potential 10-20% overhead,

... for some workloads.


> I am unclear who would enable this at initdb time.

Anybody that cares a lot about their data.

> I assume a user would wait until they suspected corruption to turn it
> on, and because it is only initdb-enabled, they would have to
> dump/reload their cluster.  The open question is whether this is a
> usable feature as written, or whether we should wait until 9.4.

When two experienced technical users tell us this is important and
that they will use it, we should listen.


> In fact, this feature is going to need
> pg_upgrade changes to detect from pg_controldata that the old/new
> clusters have the same checksum setting.

I don't see any way they can differ.

pg_upgrade and checksums don't mix, in this patch, at least.

-- 
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services