On 07/09/2026 15:26, Daniel Gustafsson wrote:
On 7 Sep 2026, at 13:08, Heikki Linnakangas <[email protected]> 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
