Craig Ringer wrote: > On 18 April 2016 at 12:11, David Rowley <david.row...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
