From: dg@illustra.com
To: stuporg@erols.com
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Lots 'o patches
Date: Mon, 1 Jun 1998 22:54:40 -0700 (PDT)
Message-ID: <9806020554.AA29494@hawk.illustra.com> (raw)
In-Reply-To: <001001bd8dbf$964de840$4299accf@darren>
>
> >
> > 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@illustra.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: dg@illustra.com, stuporg@erols.com
Subject: Re: [HACKERS] Lots 'o patches
In-Reply-To: <9806020554.AA29494@hawk.illustra.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox