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: