Re: [HACKERS] Confusing comment in pg_upgrade in regards to VACUUM FREEZE

[Craig Ringer]

On 18 April 2016 at 22:46, Alvaro Herrera  wrote:


> 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.


Right. That makes sense, and explains why nobody's been screaming in horror
as pg_upgrade takes six weeks to slowly freeze their tables ;)

The new cluster has rows created by initdb etc whose visibility information
only makes sense in the context of the control state, clog, etc of the new
cluster and we're about to clobber that. So they must be frozen.

Thanks. That feels very obvious in retrospect.

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

Re: [HACKERS] Confusing comment in pg_upgrade in regards to VACUUM FREEZE

[Alvaro Herrera]

Craig Ringer wrote:
> On 18 April 2016 at 12:11, David Rowley 
> 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 Herrerahttp://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

Re: [HACKERS] Confusing comment in pg_upgrade in regards to VACUUM FREEZE

[Craig Ringer]

On 18 April 2016 at 12:11, David Rowley 
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?

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

[HACKERS] Confusing comment in pg_upgrade in regards to VACUUM FREEZE

[David Rowley]

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers