From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(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-25 12:44:23 |
Message-ID: | CAMsr+YEGNBaTJRDsuLVR08cFTTCzGYccVOhC8ht03qu5kbakVg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 18 April 2016 at 22:46, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-04-25 12:55:54 | Re: [BUGS] Breakage with VACUUM ANALYSE + partitions |
Previous Message | Alexander Korotkov | 2016-04-25 12:34:34 | Re: Move PinBuffer and UnpinBuffer to atomics |