Hi, On Mon, Aug 31, 2026 at 02:10:15PM +0100, Zsolt Parragi wrote: > > 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]). > > Yes, I missed that in the previous version, v7 fixes it.
Thanks, yeah it fixes it. === 1 The v7-0001 commit message says: " pg_rewind keeps the target's own state, watermark and flag in the control file it installs, since most of the data directory remains the target's; replay from the last common checkpoint still adopts a state its watermark does not cover, and applies any online transition the target has not seen. " I found a case where the source's online enable occurs after divergence and was never seen by the target, but replay skips it instead of applying it: 1. Start a primary and standby with checksums off. 2. Stop the primary and promote the standby. 3. Enable checksums online on the promoted source. 4. Restart the old primary on the old timeline, advance its WAL beyond the source’s enable watermark, then enable and disable checksums online. 5. Rewind the old primary from the promoted source. The target is now off, with a watermark on the old timeline numerically greater than the source's enable records on the new timeline. pg_rewind preserves that watermark, so recovery treats those source records as already applied and skips them. Maybe the watermark needs timeline context, or pg_rewind needs to adjust it when it comes from the target's divergent history? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
