From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Confusing comment in pg_upgrade in regards to VACUUM FREEZE |
Date: | 2016-04-18 14:46:21 |
Message-ID: | 20160418144621.GA560555@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Craig Ringer wrote:
> On 18 April 2016 at 12:11, David Rowley <david(dot)rowley(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Fabrízio de Royes Mello | 2016-04-18 14:47:04 | Re: "parallel= " information is not coming in pg_dumpall for create aggregate |
Previous Message | Andres Freund | 2016-04-18 14:37:25 | Re: pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner. |