Re: Upgrading rant.

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> This would require a nontrivial amount of work (notably, we'd have to
>> be able to get pg_dump to run against a standalone backend) but I don't
>> think I'd trust pg_upgrade as a production-grade tool until its
>> invocation method looks like the above.

> I would recommend requiring users to do the schema dump before upgrading
> the binaries, so they'd do

Hm. I think we'd need to have the new version's pg_upgrade (we cannot
be sure that an older version would be aware of what information must be
dumped), and the newer pg_dump is also likely to be a better bet than
the old (we've seen several times in the past that this allows us to get
around problems in a prior version of pg_dump). But we'd need access to
the old version's postmaster/postgres executable, since by assumption
the newer one will not run in the old data directory.

I recall Lamar complaining often about the need for multiple executable
versions to be available simultaneously. Can we perhaps alter the
packaging to make this easier? I'm envisioning for example installing
the postmaster/postgres executable as "postgres.7.5", with symlinks from
"postmaster" and "postgres"; then we need not overwrite "postgres.7.4"
and that could be invoked by pg_upgrade. (I'm just brainstorming here,
this isn't necessarily a serious proposal. Better ideas anyone?)

regards, tom lane