Date: Mon, 31 Aug 2026 15:28:09 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Zsolt Parragi <zsolt.parragi@percona.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, pgsql-hackers@lists.postgresql.org
Subject: Re: Offline data checksum changes can cause incorrect checksum state
 on standbys
Message-ID: <apWdicFsT+iFxgAH@bdtpg>
References: <apGltAexjCkHPatS@bdtpg>
 <CAN4CZFMaw79Yd-sV=g=016xX3kpijD0WH3fPJEAkSusZwn7Avw@mail.gmail.com>
 <apJGv8fffeUfSkCL@bdtpg>
 <CAN4CZFMoDj7mbY231r-pmPywwJpneksUiNXDwkNokkveGtobQg@mail.gmail.com>
 <apUL3N4IE934qJ08@bdtpg>
 <8DCA12FF-0199-403D-A203-666528A25DB6@yesql.se>
 <apU0vKrffQDmmv68@bdtpg>
 <CAN4CZFNqKg9Ts76r922cKWcOgtH32ocyghQa8NLB-qeCeC1RKg@mail.gmail.com>
 <apVnwOuJBb4rHk+B@bdtpg>
 <CAN4CZFMFcgfgJ99RYhax-T+YJH=CWLy6ZGANMxf77SrSirw3VQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAN4CZFMFcgfgJ99RYhax-T+YJH=CWLy6ZGANMxf77SrSirw3VQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/apWdicFsT%2BiFxgAH%40bdtpg>
Precedence: bulk

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