Re: State of Beta 2

>>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
>
>