>>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.
>
Well to be honest. I have personally had nightmares of problems with
pg_dump. In fact I have
a large production database right now that can't use it to restore
because of the way pg_dump
handles large objects. So I can kind of see his point here. I had to
move to a rsync based backup/restore system.
The reality of pg_dump is not a good one. It is buggy and not very
reliable. This I am hoping
changes in 7.4 as we moved to a pure "c" implementation.
But I do not argue any of the other points you make below.
Sincerely,
Joshua Drake
>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
>
>