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 [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly