Excerpts from Robert Haas's message of jue mar 01 21:23:06 -0300 2012:
> On Thu, Mar 1, 2012 at 4:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> >>> So a relation can't have some pages in Version 9.2, and other pages in
> >>> version 9.3? How will this work for 2TB tables?
> >
> >> Not very well, but better than Tom's proposal to require upgrading the
> >> entire cluster in a single off-line operation.
> >
> > WTF? That was most certainly not what *I* was proposing; it's obviously
> > unworkable. We need a process that can incrementally up-version a live
> > database and keep track of the minimum version present, at some
> > granularity smaller than "whole database".
> >
> > All of this was discussed and hashed out about two years ago, IIRC.
> > We just haven't made any progress towards actually implementing those
> > concepts.
>
> I am now officially confused. I thought you and Heikki were arguing
> about 24 hours ago that we needed to shut down the old database, run a
> pre-upgrade utility to convert all the pages, run pg_upgrade, and then
> bring the new database on-line;
Actually, nobody mentioned shutting the database down. This utility
does not necessarily have to be something that runs independently from a
running postmaster; in fact what I envisioned was that we would have it
be run in a backend -- I've always imagined it's just a function to
which you give a table OID, and it converts pages of that table into the
new format. Maybe a user-friendly utility would connect to each
database and call this function for each table.
> and that, further, you were arguing that we should not support
> multiple page versions.
I don't think we need to support multiple page versions, if multiple
means > 2. Obviously we need the server to support reading *two* page
versions; though we can probably get away with having support for
*writing* only the newest page version.
(The pg_class column would mean "the oldest page version to be found in
this table", so the table can actually contain a mixture of old pages
and new pages.)
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
