Re: [REVIEW] Prototype: In-place upgrade v02

From: Abbas <abbas(dot)butt(at)enterprisedb(dot)com>
To: Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [REVIEW] Prototype: In-place upgrade v02
Date: 2008-09-28 07:58:37
Message-ID: 1222588717.8630.26.camel@abbas-laptop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I have gone through the following stuff

1) previous emails on the patch
2) http://wiki.postgresql.org/wiki/In-place_upgrade
3) http://www.pgcon.org/2008/schedule/attachments/57_pg_upgrade_2008.pdf
4) http://wiki.postgresql.org/wiki/In-place_upgrade:Storage

Here is what I have understood so far, (correct me if I am wrong)

The on disk representation of data has changed from version to version
over the years. For some strange reason (performance may be) the newer
versions of pg were not backwards compatible, meaning that the newer
version would not read data written by an older version if the on disk
representation has changed in between.
The end user would be required to port the data stored using older
version to the newer version format using offline import export.
This project aims upgrades from older to newer version on the fly.
On-disk representation is not the only change that the system should
accommodate, it should also accommodate catalog changes, conf file
changes etc.

Of the available design choices I think you have chosen to go with
on-line data conversion, meaning that pg would now be aware of all the
previous page layouts and based on a switch on page version would handle
each page layout. This will only be done to read old data, newer data
will be written in newer format.

I am supposed to test the patch and for that I have downloaded pg
versions 7.4, 8.0, 8.1, 8.2 and 8.3.

I plan to create a data directory using each of the versions and then
try to read the same using the 8.4 with your patch applied.

What database objects should I create in the test database, should I
just create objects of my choice?

Does sizes (both length and breadth) of tables matter?

Do I have to perform performance tests too?

Regards
Abbas

On Fri, 2008-09-19 at 14:28 +0200, Zdenek Kotala wrote:
> thanks
>
> Abbas napsal(a):
> > Even with that a hunk failed for bufpage.c, but I applied that part
> > manually to move on.
> > Regards
> > Abbas
> >
> > On Thu, 2008-09-18 at 12:17 +0200, Zdenek Kotala wrote:
> >> Abbas napsal(a):
> >>> Hi,
> >>> I downloaded latest postgresql source code from
> >>> git clone git://git.postgresql.org/git/postgresql.git
> >>> and tried to apply the patch
> >>> http://archives.postgresql.org/pgsql-hackers/2008-09/gza1fGXLvf3L.gz
> >>>
> >>> It does not apply cleanly, see the failures in attached file.
> >> It clash with hash index patch which was committed four days ago. Try to use
> >> little bit older revision from git (without hash index modification).
> >>
> >> Zdenek
> >>
> >>
> >>
> >
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2008-09-28 10:00:34 Re: [HACKERS] planned maintenance downtime - tribble.postgresql.org
Previous Message Greg Stark 2008-09-28 01:03:06 Re: Null row vs. row of nulls in plpgsql