From: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Manfred Koizar <mkoi-pg(at)aon(dot)at>, "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, Lamar Owen <lowen(at)pari(dot)edu>, Dennis Gearon <gearond(at)fireserve(dot)net>, Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>, PgSQL General ML <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: State of Beta 2 |
Date: | 2003-09-20 16:01:58 |
Message-ID: | 3F6C79F6.4050809@commandprompt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>>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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2003-09-20 16:04:10 | Re: This mail list and its policies |
Previous Message | Marc G. Fournier | 2003-09-20 15:57:18 | Re: State of Beta 2 |