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.
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."
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
