On Mon, 31 Aug 2026, Bertrand Drouvot <[email protected]> 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 <[email protected]> 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)
