Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Lots 'o patches

From: dg(at)illustra(dot)com (David Gould)
To: stuporg(at)erols(dot)com (Stupor Genius)
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Lots 'o patches
Date: 1998-06-02 05:54:40
Message-ID: 9806020554.AA29494@hawk.illustra.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> 
> >
> > That is going to be difficult to do.  We used to have some SQL scripts
> > that could make the required database changes, but when system table
> > structure changes, I can't imagine how we would migrate that without a
> > dump/reload.  I suppose we could keep the data/index files with user data,
> > run initdb, and move the data files back, but we need the system table
> > info reloaded into the new system tables.
> 
> If the tuple header info doesn't change, this doesn't seem that tough.
> Just do a dump the pg_* tables and reload them.  The system tables are
> "small" compared to the size of user data/indexes, no?

I like this idea.
 
> Or is there some extremely obvious reason that this is harder than it
> seems?
> 
> But then again, what are the odds that changes for a release will only
> affect system tables so not to require a data dump?  Not good I'd say.

Hmmm, not bad either, especially if we are a little bit careful not to
break existing on disk structures, or to make things downward compatible.

For example, if we added a b-tree clustered index access method, this should
not invalidate all existing tables and indexes, they just couldn't take
advantage of it until rebuilt.

On the other hand, if we decided to change to say 64 bit oids, I can see 
a reload being required.

I guess that in our situation we will occassionally have changes that require
a dump/load. But this should really only be required for the addition of a
major feature that offers enough benifit to the user that they can see that
it is worth the pain.

Without knowing the history, the impression I have formed is that we have
sort of assumed that each release will require a dump/load to do the upgrade.
I would like to see us adopt a policy of trying to avoid this unless there
is a compelling reason to make an exception.

-dg

David Gould            dg(at)illustra(dot)com           510.628.3783 or 510.305.9468 
Informix Software  (No, really)         300 Lakeside Drive  Oakland, CA 94612
"Don't worry about people stealing your ideas.  If your ideas are any
 good, you'll have to ram them down people's throats." -- Howard Aiken



In response to

Responses

pgsql-hackers by date

Next:From: David GouldDate: 1998-06-02 06:01:14
Subject: Re: [HACKERS] Current sources?
Previous:From: Billy G. AllieDate: 1998-06-02 05:00:57
Subject: Re: [HACKERS] AbortTransaction and not in in-progress state

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group