Re: [HACKERS] Checksums by default?
От | Stephen Frost |
---|---|
Тема | Re: [HACKERS] Checksums by default? |
Дата | |
Msg-id | 20170121141137.GB18360@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Checksums by default? (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
* Michael Paquier (michael.paquier@gmail.com) wrote: > On Sat, Jan 21, 2017 at 7:39 PM, Magnus Hagander <magnus@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 moving the goal-posts here about 3000 miles away and I don't believe it's necessary to have that to make this change. I agree that it'd be great to have, of course, and we're looking at if we could do something like: backup a checksum-disabled system, perform a restore which adds checksums and marks the cluster as now having checksums. If we can work out a good way to do that *and* have it work with incremental backup/restore, then we could possibly provide a small-downtime-window way to upgrade to a database with checksums. Thanks! Stephen
В списке pgsql-hackers по дате отправления: