Jon Buller <jon@bullers.net> writes:
> 
> "Johnny C. Lam" <lamj@stat.cmu.edu> wrote:
> 
> > I'm wondering what can be done about this as when PosgreSQL is
> > upgraded, a dump and restore is almost always required or at least
> > recommended.  Perhaps we should add a DEINSTALL script that warns of
> > the possible need to run pg_dumpall if the user intends to upgrade?
> > It's really far too late to tell the user to dump the databases at
> > pre-install time as it's currently done.  Any one else have thoughts
> > on how to handle this?
> 
> I think the first thing to do is modify the makefiles to print the
> output of pkg_info -R pkg_to_be_deleted just before it does the su
> to get permissions to do the delete.  That would have saved my
> bacon in this case, and probably a few others in the past too.

I generally run "pkg_info -R pkg_to_be_deleted" _before_ doing a
recursive delete anyway.  If you're lazy or forgetful, then just write
a wrapper script to do it for you before executing pkg_delete.

> 8^)  Next, a dump/restore script might be nice, but I really fear
> that it would botch the job in some odd case.  (10GB of data on an
> 18GB drive, with no room for the whole dump, anyone?) It's probably
> better to just raise some big red flags and say "Are you really,
> REALLY sure?" than to try to get the upgrade right all the time,
> in every situation.  I'm not sure I'd trust such a script anyway
> if I had real data.  Then again, if I had real data, I'd probably
> have a backup of it too. 8^)

Well, PostgreSQL used to have a pg_upgrade script, but they got rid of
it since it was unmaintained.  There are instructions in the
documentation to perform a dump using pg_dumpall, and similar
instructions on feeding the resulting file to psql to restore.

> I really need to get my PC532 back up so I can see if PostgreSQL
> needs any new NS32K tweaks since I re-did the TAS for (oh, when
> was that?) 6.4(?)

That would be cool.  I'm sure your patches will be welcome on the
pgsql-patches mailing list.

	Cheers,

     -- Johnny C. Lam <lamj@stat.cmu.edu>
        Department of Statistics, Carnegie Mellon University
        http://www.stat.cmu.edu/~lamj/