On Sun, Apr 12, 2020 at 8:05 AM Michael Paquier <michael@xxxxxxxxxxx> wrote:
On Fri, Apr 10, 2020 at 04:37:46PM -0400, Stephen Frost wrote:
> There's definitely a lot of reasons to want to have the ability to
> change an existing cluster. Considering the complications around
> running pg_upgrade already, I don't really think that changing the
> default of initdb would be that big a hurdle for folks to deal with-
> they'd try the pg_upgrade, get a very quick error that the new cluster
> has checksums enabled and the old one didn't, and they'd re-initdb the
> new cluster and then re-run pg_upgrade to figure out what the next issue
> is..
We discussed that a couple of months ago, and we decided to keep that
out of the upgrade story, no? Anyway, if you want to enable or
disable data checksums on an existing cluster, you always have the
possibility to use pg_checksums --enable. This exists in core since
12, and there is also a version on out of core for older versions of
Postgres: https://github.com/credativ/pg_checksums. On apt-based
distributions like Debian, this stuff is under the package
postgresql-12-pg-checksums.
The fact that this tool exists, and then in the format of pg_checksums --disable, I think is what makes the argument to turn on checksums by default possible. Because it's now very easy and fast to turn it off even if you've accumulated sizable data in your cluster. (Turning it on in this case is easy, but not fast).
And FWIW, I do think we should change the default. And maybe spend some extra effort on the message coming out of pg_upgrade in this case to make it clear to people what their options are and exactly what to do.
