Re: Confusing comment in pg_upgrade in regards to VACUUM FREEZE

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

In response to

Browse pgsql-hackers by date

  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