Hi, On Mon, Aug 31, 2026 at 11:55:01AM +0100, Zsolt Parragi wrote: > > Yeah, I see your point that the underlying issue is the non WAL logged > > change. > > My concern was not about a pg_control change in itself, but that addressing > > this > > case might require further changes to the current pg_control design, which > > adds > > risk this close to RC1. > > I don't think we can get this completely right without both wal and > pg_control changes (and possibly some extra connection-time > communication between the standby and primary to provide early > reporting instead of delayed in the most common cases) > If we want to move toward the error direction in pg20 (which we > should) we will have to log that an offline change happened. > > I attached v6 which for now documents the current behavior as-is, and > other than that I reorganized the test files.
Thanks! I did not look in details but it looks like that pg_upgrade --check against a running source cluster with checksums enabled will still fail (finding === 2 in [0], tested with the test shared in [1]). [0]: https://postgr.es/m/apUL3N4IE934qJ08%40bdtpg [1]: https://postgr.es/m/apU4/hmRv/4gv20W%40bdtpg Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
