Hi, On Mon, Aug 31, 2026 at 09:16:52AM +0200, Daniel Gustafsson wrote: > > On 31 Aug 2026, at 07:06, Bertrand Drouvot <[email protected]> > > wrote: > > > > 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. > > I think we really need to think about documenting a lot of this, potentially > even to the point of saying that offline and online changes should not be > mixed
Yeah, that could make sense, at least to make the limitation explicit and warn users about these cases. > as they work with completely different durability models. Yeap. > The more I think about this the less excited I am about contorting the logic > of > a feature which does proper WAL logging to cope with a tool that doesn't, > including misuses like creating mismatched clusters. We should probably start > to look at improving pg_checksums such that transitions are WAL logged rather > than shoehorning in such changes with a WAL logged flow. pg_checksums > rewrites > the datadirectory without the postmaster given any information that any change > was made, which in itself should be a red flag. I agree. > Making sure that StartupXLOG > can detect the offline change (or something along those lines) and properly > log > it seems like a better starting point. That sounds worth exploring. Would the idea be for pg_checksums to leave a marker in pg_control which StartupXLOG would turn into a WAL logged transition? > >>> Do you see the control version change as a concern? > >> > >> Yes, it is another non-trivial change in an already complex patch, > >> really close to RC1. It's also not an area where we could easily > >> implement bug fixes in a minor version, if we discover something > >> later. > > > > Yeah, and I think the case above reinforces that concern. > > 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. Yeah, I see your point that the underlying issue is the non WAL logged change. My concern was not about a pg_control change in itself, but that addressing this case might require further changes to the current pg_control design, which adds risk this close to RC1. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
