Re: Offline data checksum changes can cause incorrect checksum state on standbys

On 07/09/2026 15:26, Daniel Gustafsson wrote:
>> On 7 Sep 2026, at 13:08, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> I think these paragraphs could use some copy-editing too. It feels like a pretty deep technical explanation, not very accessible to a DBA. Maybe start with "The primary server and replica can have different checksum states".
>
> Can, but really really shouldn't =)

:-D

>> I'm still trying to understand all the different states and interactions between online and offline changes. It's really complicated :-(. I know it's a tall order, but is there something we could do to make it simpler?
>
> If there was I'd love to try it, but across the many alteratives tried during
> this open item there hasn't been anyhing less complicated which also solves the
> problem. Combining a WAL logged procedure with one that can rewrite the data
> directory without any WAL entries at all is inherently complicated.

So, if you can have different state in primary and a replica, there are
four combinations:

1: Primary on, replica on
2: Primary off, replica off

These are straightforward

3: Primary on, replica off

You end up in this situation, if you turn on run pg_checksums to turn on
checksums in primary. You stay that you really really shouldn't stay for
long in this state, but why? What's the harm?

One harm is that it's confusing, but if we have to deal with it anyway,
why is it so bad?

4: Primary off, replica on

Is this possible? Does it make sense?

>> Would it help if there was a separate flag in the control file for "checksums enabled in primary" and "checksums enabled in this replica", for example?
>
> Not sure I follow, should pg_checksums maintan such a flag or the StartupXLOG?

I don't know. It was just thought, probably a bad one...

- Heikki