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

> On 7 Sep 2026, at 17:57, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:

>>> 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?

Tools like pg_rewind etc rely on the fact that nodes are equal in checksum
state. What if the replica is promoted? I'm personally unconvinced that there
is a good usecase for per-node settings, but I've spent X years thinking about
checksums being replicated so I am clearly biased.

Considering how complicated it was to get replicated states right, if we want
to make it per-node I think we need to go back to the drawing board and
re-think properly rather than settle for that it seems to work. (Not that I
think that's what you're advocating, I just expect getting it work will be
complicated.)

> 4: Primary off, replica on
>
> Is this possible? Does it make sense?

This is possible using pg_checksums, but like the inverse case I don't think it
makes sense to use different settings across replication.

--
Daniel Gustafsson