From: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_upgrade: What is changed? |
Date: | 2006-08-24 17:59:41 |
Message-ID: | 44EDE90D.3030305@sun.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim C. Nasby wrote:
> On Wed, Aug 23, 2006 at 10:49:05AM +0200, Martijn van Oosterhout wrote:
>>> 8) WAL/XLOG
>>> Question: Should be deleted?
>> I imagine you should probably force a checkpoint and then wipe the wal
>> records. The WAL isn't going to be able to cover some of the stuff done
>> during the upgrade, so it'd be useless after anyway.
>
> Is there any way around that? If WAL can't be trusted that means if you
> crash during update, you're hosed. Which means you need to backup the
> database before upgrading, which greatly increases downtime. Same
> applies to having to reindex everything.
By my opinion upgrade process should fail for example during catalog
adjustment. This step probably will not have any record in the WAL and
you will stay in the middle and ... you will start looking for backup.
> Granted, *any* kind of upgrade not requiring a dump/restore is a major
> improvement.
Any really good DBA never do upgrade without backup. It is too dangerous
operation. By the way, you can do backup without downtime. Yes, you lost
all data after backup. It is risk and DBA must make decision if it is
acceptable or not.
Is possible play WAL to get lost data after backup? If yes, you can
backup on-line database and first step of upgrade should be move WAL to
the safe place.
Zdenek
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Kaltenbrunner | 2006-08-24 17:59:48 | Re: tsvector/tsearch equality and/or portability issue |
Previous Message | Tom Lane | 2006-08-24 17:50:05 | Re: tsvector/tsearch equality and/or portability issue issue ? |