On Sat, Apr 18, 2020 at 12:19 AM Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Apr 16, 2020 at 11:37 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > > Then of course frozenXID can be advanced with eg update pg_database > > set datallowconn = 't' where datname = 'template0', then vacuumdb > > --freeze --all, and checked before and after with Robert's > > pg_old_snapshot_time_mapping() SRF to see that it's truncated. But > > it's not really the level of stuff we'd ideally mess with in > > pg_regress tests and I don't see any precent, so I guess maybe I'll > > need to go and figure out how to write some perl. > > The reason I put it in contrib is because I thought it would possibly > be useful to anyone who is actually using this feature to be able to > look at this information. It's unclear to me that there's any less > reason to provide introspection here than there is for, say, pg_locks.
Makes sense. I was talking more about the pg_clobber_snapshot_timestamp() function I showed, which is for use by tests, not end users, since it does weird stuff to internal state. > It's sorta unclear to me why you continued the discussion of this on > this thread rather than the new one I started. Seems like doing it > over there might be clearer. I understood that you'd forked a new thread to discuss one particular problem among the many that Andres nailed to the door, namely the xid map's failure to be monotonic, and here I was responding to other things from his list, namely the lack of defences against wrap-around and the lack of testing. Apparently I misunderstood. I will move to the new thread for the next version I post, once I figure out if I can use pg_clobber_snapshot_timestamp() in a TAP test to check early vacuum/pruning behaviour.
