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

Thanks!

I agree that v4 is not a complete fix, and we could make it better.
The question is the balance, as every change also makes it more
complex. The main point of it is to try to minimize how invasive of a
patch it is, and making sure that offline changes work and don't
result in completely breaking a standby.

1: this is a valid issue, but requires somebody doing an offline
change immediately after an online change. The effect is that in this
case, the standby might roll back the offline change, but it will
print out a warning about this into the log, so this is visible, and
everything will continue working.

2: my understanding is that if there's a concurrent checkpoint and a
crash shortly after it, we might throw away an otherwise completed
online checksum after restarting. We properly log that checksums were
interrupted, and the state remains "off" on all nodes. While this is
not ideal, I think this is an unlikely scenario and not the only such
issue, for example a failing DROP DATABASE foo FORCE similarly can
interrupt checksums in an unlikely case, as I reported in another
thread.

3: also valid, but in my repro of this the warning fired, so it's not
silent, and things seem to work fine after the warning, and the user
can issue either an online or an offline change.

4: I couldn't construct a repro for this case, I think this can only
happen in theory in very specific engineered scenarios

> FWIW, while v4-0001 may address other issues present in v1, v1 would avoid the
> specific cases described in === 1 through === 3. Some parts of it may therefore
> be worth considering here.

I agree that combining the two patches would be the best solution in
the warning direction, e.g. solving 1+3 requires the pg_control
changes from v1. The reason I left that out is what I started with in
this reply: simplicity. I was mainly considering combining the two
because of v4 can emit spurious warnings in some cases (and then the
additional log state stating the correction), but even with these I am
not sure if we should make it more complex, as none of these result in
crashes/data corruption, only in state rolling back in some
engineering situations. I'll try to look into what adding the two
patches together looks like, but it most likely combines their size,
as they improve the current master code in different ways.