Re: pg_upgrade project status

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade project status
Date: 2008-11-11 15:12:49
Message-ID: 200811111512.mABFCnJ00899@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zdenek Kotala wrote:
> Bruce Momjian napsal(a):
> > Zdenek Kotala wrote:
> >> In the last week community made decision about pg_upgrade project and its
> >> implementation. I would like to try summarize this conclusion and I add other
> >> topic which should be finished for 8.4.
> >>
> >> Convert on read has been selected as a good way, because it is not invasive and
> >> does not limit fresh database. But, this way needs core modification which
> >> allows to do online in-place upgrade. It means no online in-place upgrade to 8.4
> >> will be implemented. Sorry about that, but we need move forward and there is not
> >> easy way without core modification to do it.
> >>
> >> As I mentioned manytimes before there are two major issues with convert on read
> >> and one small issue.
> >>
> >> 1) Data does not fit on the new page. It will be solve by pre-upgrade check
> >> which reserve space on each page, before upgrade.
> >
> > Rather than specifying free space as an amount, I was thinking of having
> > a boolean like 'ready_for_upgrade' and the system internally would know
> > how much free space for each page and tuple.
>
> You need booth, flag which shows you that the relation/database is ready for
> upgrade and free space reservation configuration for each column. System cannot
> know it because PostgreSQL is not oracle :-). It does not know what will happend
> during next version development :-). It have to be setup by pre-upgrade script.

So every Postgres version will allow space reservation based on the
table and page, and the pre-upgrade script will set those values based
on the table's columns --- makes sense, and avoids the need for a minor
update to Postgres to add new code --- good idea.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Huxton 2008-11-11 15:16:25 Re: Very slow queries w/ NOT IN preparation (seems like a bug, test case)
Previous Message Magnus Hagander 2008-11-11 15:04:40 Re: libpq with ssl vs psql without