On Wed, Aug 3, 2022 at 1:20 PM Andres Freund <and...@anarazel.de> wrote: > > I don't really like this approach. Imagine that the code got broken in > > such a way that relfrozenxid and relminmxid were set to a value chosen > > at random - say, the contents of 4 bytes of unallocated memory that > > contained random garbage. Well, right now, the chances that this would > > cause a test failure are nearly 100%. With this change, they'd be > > nearly 0%. > > Can't that pretty easily be addressed by subsequently querying txid_current(), > and checking that the value isn't newer than that?
It couldn't hurt to do that as well, in passing (at the same time as testing that newrelfrozenxid >= oldrelfrozenxid directly). But deliberately running VACUUM afterwards seems like a good idea. We really ought to expect VACUUM to catch cases where relfrozenxid/relminmxid is faulty, at least in cases where it can be proven wrong by noticing some kind of inconsistency. -- Peter Geoghegan
