Re: 16-bit page checksums for 9.2 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: 16-bit page checksums for 9.2
Date
Msg-id CA+TgmobLwPifr72SgzMftm=cxQ3-feHnP=1nKJFYiG2P-fpU_g@mail.gmail.com
Whole thread Raw
In response to Re: 16-bit page checksums for 9.2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 16-bit page checksums for 9.2
List pgsql-hackers
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; and that, further, you were arguing
that we should not support multiple page versions.  Now you seem to be
arguing the exact opposite - namely, that we should support multiple
page versions, and that the conversion should be done on-line.

So, to reiterate, I'm lost.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Marti Raudsepp
Date:
Subject: Re: Caching for stable expressions with constant arguments v6
Next
From: Alvaro Herrera
Date:
Subject: Re: 16-bit page checksums for 9.2