> On 7 Sep 2026, at 17:57, Heikki Linnakangas <[email protected]> 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
