Re: (A) native Windows port

Lamar Owen wrote:
> 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.

Sure, if it wasn't a kludge, I wouldn't have written it. ;-)

Does everyone remember my LIKE indexing kludge in gram.y? Until people
found a way to get it into the optimizer, it did its job. I guess
that's where pg_upgrade is at this point.

Actually, how can pg_upgrade be improved?

Also, we have committed to making file format changes for 7.3, so it
seems pg_upgrade will not be useful for that release unless we get some
binary conversion tool working.

> 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.

Yep.

> 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.

I should mention that 7.3 will have pg_depend, which should make our
post-7.3 reload process much cleaner because we will not have dangling
objects as often.

> And the Windows user will likely demand it. I never thought I'd be grateful
> for a Win32 native PostgreSQL port... :-)

Yea, the trick is to get an something working that will require minimal
change from release to release.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026