Re: [WIP] In-place upgrade

From: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
To: Decibel! <decibel(at)decibel(dot)org>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [WIP] In-place upgrade
Date: 2008-11-10 08:15:13
Message-ID: 4917ED91.5080302@sun.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Decibel! napsal(a):

> Unless I'm mistaken, there are only two cases we care about for
> additional space: per-page and per-tuple.

Yes. And maybe special space indexes could be extended, but it is covered in
per-page setting.

> Those requirements could also
> vary for different types of pg_class objects. What we need is an API
> that allows an administrator to tell the database to start setting this
> space aside. One possibility:

We need API or mechanism how in-place upgrade will setup it. It must be done by
in-place upgrade.

<snip>

> relkind: Essentially, heap vs toast, though I suppose it's possible we
> might need this for sequences.

Sequences are converted during catalog upgrade.

<snip>
> Once we have an API, we need to get users to make use of it. I'm
> thinking add something like the following to the release notes:
>
> "To upgrade from a prior version to 8.4, you will need to run some of
> the following commands, depending on what version you are currently using:
>
<snip>

It is too complicated. At first it depends also on architecture and it is
possible to easily compute by in-place upgrade script. What you need is only run
script which do all setting for you. You can obtain it from next version (IIRC
Oracle do it this way) or we can add this configuration script into previous
version during a minor update.

>
> OTOH, we might not want to go mucking around with changing the catalog
> for older versions (I'm not even sure if we can). So perhaps it would be
> better to store this information in a separate table, or maybe a
> separate file. That might be best anyway; we generally wouldn't need
> this information, so it would be nice if it wasn't bloating pg_class all
> the time.

It is why I selected relopt for storing this configuration parameter, which is
supported from 8.2 and upgrade from 8.1->8.2 works fine.

Zdenek

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-11-10 08:21:48 Re: WIP: Page space reservation (pgupgrade)
Previous Message Martijn van Oosterhout 2008-11-10 08:05:01 Re: WIP: Page space reservation (pgupgrade)