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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
