On Tuesday 02 July 2002 03:14 pm, Jan Wieck wrote:
> Lamar Owen wrote:
> > [...]
> > Martin O has come up with a 'pg_fsck' utility that, IMHO, holds a great
> > deal of promise for seamless binary 'in place' upgrading. He has been
> > able to write code to read multiple versions' database structures --
> > proving that it CAN be done.
> Unfortunately it's not the on-disk binary format of files that causes
> the big problems. Our dump/initdb/restore sequence is also the solution
> for system catalog changes.
Hmmm. They get in there via the bki interface, right? Is there an OID issue
with these? Could differential BKI files be possible, with known system
catalog changes that can be applied via a 'patchdb' utility? I know pretty
much how pg_upgrade is doing things now -- and, frankly, it's a little bit of
a kludge.
Yes, I do understand the things a dump restore does on somewhat of a detailed
level. I know the restore repopulates the entries in the system catalogs for
the restored data, etc, etc.
Currently dump/restore handles the catalog changes. But by what other means
could we upgrade the system catalog in place?
Our very extensibility is our weakness for upgrades. Can it be worked around?
Anyone have any ideas?
Improving pg_upgrade may be the ticket -- but if the on-disk binary format
changes (like it has before), then something will have to do the binary
format translation -- something like pg_fsck.
Incidentally, pg_fsck, or a program like it, should be in the core
distribution. Maybe not named pg_fsck, as our database isn't a filesystem,
but pg_dbck, or pg_dbcheck, pr pg_dbfix, or similar. Although pg_fsck is
more of a pg_dbdump.
I've seen too many people bitten by upgrades gone awry. The more we can do in
the regard, the better.
And the Windows user will likely demand it. I never thought I'd be grateful
for a Win32 native PostgreSQL port... :-)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11