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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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