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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026