Thread: Confusing comment in pg_upgrade in regards to VACUUM FREEZE

I'd been wondering why a VACUUM FREEZE is performed during pg_upgrade,
so I opened up the code to see if that would help me determine why
this is.

I'm confronted with a comment, which states;

/*
* We do freeze after analyze so pg_statistic is also frozen. template0 is
* not frozen here, but data rows were frozen by initdb, and we set its
* datfrozenxid, relfrozenxids, and relminmxid later to match the new xid
* counter later.
*/

this is not helping me much as I don't really understand why
pg_statistic need to be frozen?

-- David Rowley                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services

Craig Ringer wrote:
> On 18 April 2016 at 12:11, David Rowley <david.rowley@2ndquadrant.com>
> wrote:
> 
> > this is not helping me much as I don't really understand why
> > pg_statistic need to be frozen?
> 
> Yeah, in particular it's not clear to me why pg_upgrade goes to such
> efforts to freeze everything when it copies pg_clog over in
> copy_clog_xlog_xid() .
> 
> Is it mainly a defense against the multixact format change?

Nothing to do with that.  The VACUUM FREEZE is executed on the new
database before migrating the old data over; it's there so that the
existing data has no trace of any permanent "normal" Xids from the
original counter.  Immediately afterwards we use pg_resetxlog to set the
counters to different values, and the normal values might be in a range
not covered by those, or they could even be marked aborted.  So a
visibility test would error out or return the wrong thing.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services