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

On Mon, 31 Aug 2026, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> I did some more testing and realized that stopping both nodes is not sufficient
> to prevent a mismatch in all cases.
...
> Fixing this would probably require recording additional ordering information for
> offline changes, adding even more complexity to v5. Another option would be to
> document that the standby must be fully caught up before both nodes are stopped
> for the offline operation.

This is one of the variations I mentioned earlier, that we can emit
spurious warnings in some cases, and later state that the state
restored, and print a log about that. And with that, this is one f the
main reasons why I thought we shouldn't try to make it an error in 19.

This is reachable in even simpler, not so engineered scenarios. I
added the logging of restored state especially for cases like this, so
we can later see that the warning resolved itself.

On Mon, 31 Aug 2026, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> I don't think the above reinforces not wanting to do a pg_control change at
> this point. I think it reinforces that changing datafiles without WAL logging
> is a fairly slippery slope.

We can simply prevent this (in this case) by not printing out any
warnings until we reached the primary's LSN, the standby already
receives this information at connection time. I have a patch for it,
but it was again a bit more complex than I initially hoped for. (and
even then, we will still have a few corner-cases left with spurious
warnings, if I remember correctly even with that there would be still
an issue with chaining standbys, that needs another fix)