Re: [WIP] In-place upgrade

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [WIP] In-place upgrade
Date: 2008-11-05 12:43:26
Message-ID: 491194EE.8040603@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas napsal(a):
> Zdenek Kotala wrote:

>
> We've talked about this many times before, so I'm sure you know what my
> opinion is. Let me phrase it one more time:
>
> 1. You *will* need a function to convert a page from old format to new
> format. We do want to get rid of the old format pages eventually,
> whether it's during VACUUM, whenever a page is read in, or by using an
> extra utility. And that process needs to online. Please speak up now if
> you disagree with that.

Yes. Agree. The basic idea is to create new empty page and copy+convert tuples
into new page. This new page will overwrite old one I have already code which
converts heap table (excluding arrays and composite datatype).

> 2. It follows from point 1, that you *will* need to solve the problems
> with pages where the data doesn't fit on the page in new format, as well
> as converting TOAST data.

Yes or no. It depends if we will want live with old pages forever. But I think
convert all pages to the newest version is good idea.

> We've discussed various solutions to those problems; it's not
> insurmountable. For the "data doesn't fit anymore" problem, a fairly
> simple solution is to run a pre-upgrade utility in the old version, that
> reserves some free space on each page, to make sure everything fits
> after converting to new format.

I think it will not work. you need protect also PotgreSQL to put any data extra
data on a page. Which requires modification into PostgreSQL code in old branches.

> For TOAST, you can retoast tuples when
> the heap page is read in.

Yes you have to retosted it which is only possible method but problem is thet
you need workinig toastable index ... yeah, indexes are different story.

> I'm not sure what the problem with indexes is,
> but you can split pages if necessary, for example.

Indexes is different story. In first step I prefer to use reindex. But in the
future a prefer to extend pg_am and add ampageconvert which will point to
conversion function. Maybe we can extend it now and keep this column empty.

> Assuming everyone agrees with point 1, could we focus on these issues?

Yes, OK I'm going to cleanup code which I have and I will send it soon. Tuple
conversion is already part of patch which I already send. See
access/heapam/htup_03.c.

Zdenek

--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2008-11-05 12:46:56 Re: some strange bugs related to upgrade from 8.1 to 8.3
Previous Message Stefan Kaltenbrunner 2008-11-05 12:40:45 Re: WIP parallel restore patch