On Sat, Apr 18, 2020 at 12:19 AM Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Apr 16, 2020 at 11:37 PM Thomas Munro <thomas.munro@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.