Re: [HACKERS] Checksums by default?
| От | Magnus Hagander |
|---|---|
| Тема | Re: [HACKERS] Checksums by default? |
| Дата | |
| Msg-id | CABUevEzARXo+jdwGhMk7NOyVsmue-9LJRnqa4tOVrtZSAv1FEQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Checksums by default? (Michael Paquier <michael.paquier@gmail.com>) |
| Ответы |
Re: [HACKERS] Checksums by default?
|
| Список | pgsql-hackers |
On Sat, Jan 21, 2017 at 3:05 PM, Michael Paquier <michael.paquier@gmail.com> wrote:
That's a different usecase though.
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 a different usecase though.
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.
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 :)
В списке pgsql-hackers по дате отправления: