Re: State of Beta 2 - Mailing list pgsql-general

From Mark Cave-Ayland
Subject Re: State of Beta 2
Date
Msg-id 8F4A22E017460A458DB7BBAB65CA6AE50264E0@webbased9
Whole thread Raw
In response to State of Beta 2  (Andrew Rawnsley <ronz@ravensfield.com>)
Responses Re: State of Beta 2
List pgsql-general
> Date: Tue, 16 Sep 2003 14:39:47 -0700
> From: "Joshua D. Drake" <jd@commandprompt.com>
> To: Andrew Rawnsley <ronz@ravensfield.com>
> Cc: "Marc G. Fournier" <scrappy@postgresql.org>,
>    PgSQL General ML <pgsql-general@postgresql.org>
> Subject: Re: State of Beta 2
> Message-ID: <3F678323.7000708@commandprompt.com>
>
> >
> > Tying to my last post, concerning Joshua's offer to put up the labor

> > if we can put up the dough, given the
> > fact that Postgres is still in flux, do you think its even possible
to
> > do some sort of in-place upgrade, not knowing
> > what may come up when you're writing 7.6?
> >
> > In other words, if we pony up and get something written now, will it

> > need further development every time an x.y release comes up.
>
> There is probably no question that it will need further development.
> However, I would imagine that once the intial grunt work is done it
> would be much easier to migrate the code (especially if it is
> continually maintained) to newer releases.
>
> My thought process is that we would start with 7.4 codebase and as it
> migrates to 7.5 move the work directly to 7.5 and if possible release
> for 7.5 (although that really may be pushing it).
>
> J

While everyone is throwing around ideas on this one.....

Would it not be possible to reserve the first few pages of each file
that stores tuples to store some metadata that describes the on-disk
structure and the DB version? If the DB version in the existing files
doesn't match the current version of the postmaster then it
automatically launches pg_upgrade on startup.

Hopefully this would minimise the work that would need to be done to
pg_upgrade between versions, since the only changes between versions
would be to provide the mappings between the on-disk structures of the
existing files (which could easily be determined by parsing the metadata
from the existing files) and the modified on-disk structure required by
the new version. (Ok I know this doesn't deal with the catalog issues
but hopefully it would be a step in the right direction).


Cheers,

Mark.

---

Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England

Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446


This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender. You
should not copy it or use it for any purpose nor disclose or distribute
its contents to any other person.



pgsql-general by date:

Previous
From: Andreas Fromm
Date:
Subject: Re: char o varchar
Next
From: Kaare Rasmussen
Date:
Subject: Re: State of Beta 2