Magnus, * Magnus Hagander (mag...@hagander.net) wrote: > On Sat, Jan 21, 2017 at 3:05 PM, Michael Paquier <michael.paqu...@gmail.com> > wrote: > > > On Sat, Jan 21, 2017 at 7:39 PM, Magnus Hagander <mag...@hagander.net> > > wrote: > > > Is it time to enable checksums by default, and give initdb a switch to > > turn > > > it off instead? > > > > > > I keep running into situations where people haven't enabled it, because > > (a) > > > they didn't know about it, or (b) their packaging system ran initdb for > > them > > > so they didn't even know they could. And of course they usually figure > > this > > > out once the db has enough data and traffic that the only way to fix it > > is > > > to set up something like slony/bucardo/pglogical and a whole new server > > to > > > deal with it.. (Which is something that would also be good to fix -- but > > > having the default changed would be useful as well) > > > > Perhaps that's not mandatory, but I think that one obstacle in > > changing this default is to be able to have pg_upgrade work from a > > checksum-disabled old instance to a checksum-enabled instance. That > > would really help with its adoption. > > That's a different usecase though.
Agreed. > If we just change the default, then we'd have to teach pg_upgrade to > initialize the upgraded cluster without checksums. We still need to keep > that *option*, just reverse the default. Just to clarify- pg_upgrade doesn't init the new database, the user (or a distribution script) does. As such *pg_upgradecluster* would have to know to init the new cluster correctly based on the options the old cluster was init'd with, but it might actually already do that (not sure off-hand), and, even if it doesn't, it shouldn't be too hard to make it to that. > Being able to enable checksums on the fly is a different feature. Which I'd > really like to have. I have some unfinished code for it, but it's a bit too > unfinished so far :) Agreed. Thanks! Stephen
signature.asc
Description: Digital signature
