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

On Wed, 17 Sep 2003, Mark Cave-Ayland wrote:

> > 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).
>
>
    Silly point I know. But...

    I don't mind really having to rebuild the database from backup too
gain new features. What I really can't stand is that every new version
breaks half the clients. A Client that worked with 7.1 should still work
with 7.4.
    This is because much of the meta-data about the database is only
available from system catalogs.
    I know there is a standard for Meta-data available for SQL but
nobody follows it.
    If the clients did not break (like the did with 7.3) you could
then write the upgrade program as a client.

1. Initalises its own database root. With old database still running
2. Reads the old database. Into its new dataroot. (Backup like pgdump...)
3. Close Down Old Database
4. Open New Database properly
5. Delete New Database.

    This way the database *should* only be down for a few seconds
while we actually swap postmasters.
    This should even be faster (or seam faster) than modifying on-disk
stuctures because the database is only down for the time it takes to stop
one postmaster and start the new.
    The only problem I can see is the need to have lots of free disk
space to store two databases.....
    Replication would also help this if it ever gets finished!

Peter Childs