Manfred Koizar <mkoi-pg@aon.at> writes:
> I'm more in favour of in-place upgrade. This might seem risky, but I
> think we can expect users to backup their PGDATA directory before they
> start the upgrade.
> I don't trust pg_dump because
You don't trust pg_dump, but you do trust in-place upgrade? I think
that's backwards.
The good thing about the pg_upgrade process is that if it's gonna fail,
it will fail before any damage has been done to the old installation.
(If we multiply-link user data files instead of moving them, we could
even promise that the old installation is still fully valid at the
completion of the process.) The failure scenarios for in-place upgrade
are way nastier.
As for "expect users to back up in case of trouble", I thought the whole
point here was to make life simpler for people who couldn't afford the
downtime needed for a complete backup. To have a useful backup for an
in-place-upgrade failure, you'd have to run that full backup after
stopping the old postmaster, so you are still looking at long downtime
for an update.
> it doesn't help when the old postmaster binaries are not longer
> available
[shrug] This is a matter of design engineering for pg_upgrade. The fact
that we've packaged it in the past as a script that depends on having
the old postmaster executable available is not an indication of how it
ought to be built when we redesign it. Perhaps it should include
back-version executables in it. Or not; but clearly it has to be built
with an understanding of what the total upgrade process would look like.
regards, tom lane
