Thread: Re: pg_upgrade: Support for upgrading to checksums enabled
On Mon, Aug 26, 2024 at 08:23:44AM +0200, Peter Eisentraut wrote: > The purpose of this patch is to allow using pg_upgrade between clusters that > have different checksum settings. When upgrading between instances with > different checksum settings, the --copy (default) mode automatically sets > (or unsets) the checksum on the fly. > > This would be particularly useful if we switched to enabling checksums by > default, as [0] proposes, but it's also useful without that. Given enabling checksums can be rather expensive, I think it makes sense to add a way to do it during pg_upgrade versus asking folks to run pg_checksums separately. I'd anticipate arguments against enabling checksums automatically, but as you noted, we can move it to a separate option (e.g., --copy --enable-checksums). Disabling checksums with pg_checksums is fast because it just updates pg_control, so I don't see any need for --disable-checkums in pg_upgrade. > - Windows has a separate code path in the --copy mode. I don't know the > reasons or advantages of that. So it's not clear how the checksum rewriting > mode should be handled in that case. We could switch to the non-Windows > code path in that case, but then the performance difference between the > normal path and the checksum-rewriting path is even more unclear. AFAICT the separate Windows path dates back to before pg_upgrade was first added to the Postgres tree, and unfortunately I couldn't find any discussion about it. -- nathan
On Tue, Aug 27, 2024 at 5:57 PM Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Mon, Aug 26, 2024 at 08:23:44AM +0200, Peter Eisentraut wrote: > > The purpose of this patch is to allow using pg_upgrade between clusters that > > have different checksum settings. When upgrading between instances with > > different checksum settings, the --copy (default) mode automatically sets > > (or unsets) the checksum on the fly. > > > > This would be particularly useful if we switched to enabling checksums by > > default, as [0] proposes, but it's also useful without that. > > Given enabling checksums can be rather expensive, I think it makes sense to > add a way to do it during pg_upgrade versus asking folks to run > pg_checksums separately. I'd anticipate arguments against enabling > checksums automatically, but as you noted, we can move it to a separate > option (e.g., --copy --enable-checksums). Disabling checksums with > pg_checksums is fast because it just updates pg_control, so I don't see any > need for --disable-checkums in pg_upgrade. > The repercussions of either enabling or disabling checksums on accident is quite high (not for pg_upgrade, but for $futureDBA), so ISTM an explicit flag for BOTH is the right way to go. In that scenario, pg_upgrade would check to make sure the clusters match and then make the appropriate suggestion. In the case someone did something like --enable-checksums and --link, again, we'd toss an error that --copy mode is required to --enable-checksums. Robert Treat https://xzilla.net