Re: WIP checksums patch

On Mon, Nov 12, 2012 at 12:39:17AM -0500, Greg Smith wrote:
> On 11/9/12 6:14 PM, Jeff Davis wrote:
> >On Mon, 2012-11-05 at 12:19 -0500, Robert Haas wrote:
> >>Yeah. I definitely think that we could shed an enormous amount of
> >>complexity by deciding that this is, for now, an option that can only
> >>be selected at initdb time. That would remove approximately 85% of
> >>everything I've ever disliked about this patch - without, I think,
> >>precluding the possibility of improving things later.
> >
> >That's certainly true, but it introduces one large problem: upgrading
> >would not work, which (in the past few releases) we've treated as a
> >major showstopper for many features.
>
> If you have pages that were written with one datetime storage
> format, and you create a cluster using the other one, that will
> fail. If checksums are done as an initdb time option, I see
> "checksummed" as being a block change on that level, and the
> precedent for not supporting it defensible. pg_upgrade will need to
> check for a mismatch--new cluster has checksums turned on, old one
> doesn't--and abort out if that happens. That can be lumped in with
> the other pg_controldata tests easily enough.

Yes, pg_upgrade can do that easily.

> What I think this argues for, though, is being precise about naming
> what goes into pg_controldata. Let's say the initial commit target
> is an initdb time switch, but later finer grained ones are expected
> to be available. I think the output and source code labels on the
> initdb controldata part should refer to this as something like
> "checksums available" then. The word "enabled" could be misleading
> when there's finer grained enabling coming later. We don't want
> people to run pg_controldata, see "checksums: enabled/on", and
> later discover they're not fully operational in that cluster yet.
> Saying "checksums: available" suggests there's somewhere else that
> should be checked, to tell if they're available on a given
> database/table or not.
>
> The sort of text I'm thinking of for the manual and/or warning is:
>
> "You can't use pg_upgrade to migrate from a cluster where checksums
> are not available to one where they are. This limitation may be
> removed by a future version."

"available" sounds like it is compiled in, but in this case, it means it
is active. I think we are just going to need to rename it as we make it
finer grained.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +