Hi, On Thu, Aug 13, 2026 at 12:17:16PM +0200, Daniel Gustafsson wrote: > > On 12 Aug 2026, at 02:29, Fujii Masao <[email protected]> wrote: > > > > On Tue, Aug 11, 2026 at 11:56 PM Daniel Gustafsson <[email protected]> wrote: > >> I'm leaning towards using an integer representation in v19, which is the > >> safe > >> option, and rethink it for v20 when we can consider it without any rush. A > >> compromise could be do document the integer <=> state name mapping in the > >> checksums section in the docs. > > > > +1 to keep using "version" for now and clarify the mapping in the docs. > > I took a stab at fixing this today and in doing so I realized another issue > which isn't directly related to online checksums but also affect the offline > checksums available in all supported versions. pg_control_init is documented > to return the state at cluster initialization, but the checksum version in the > controlfile is overwritten when changed, and the original value is lost. The > attached 0001 fixes this by adding a new field to the controlfile. I think > this should be backpatched to 19, but it could also be argued against that at > this point in the cycle since it's a pre-existing regression (especially since > it updates the controlfile format). > > The 0002 use data_page_checksum_version consistently, adds a mapping table to > the documentation and fixes the tests.
Thanks for the updates! I've a few comments: === 1 +# Regardless of the new state, pg_control_init() should still report checksums +# as off. Could we also test the opposite case and ensure pg_control_init() still reports 1? Also, as 0001 fixes the offline case too, worth checking pg_checksums leaves the value reported by pg_control_init() unchanged? And should this test be part of 0001 instead of 0002? === 2 + version using an integer representation due to how they were originally + implementated. s/implementated/implemented/ Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
