| From: | Matthew Kirkwood <matthew(at)hairy(dot)beasts(dot)org> |
|---|---|
| To: | mlw <markw(at)mohawksoft(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Why dump/restore to upgrade? |
| Date: | 2002-02-08 13:25:59 |
| Message-ID: | Pine.LNX.4.33.0202081319170.20623-100000@sphinx.mythic-beasts.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 8 Feb 2002, mlw wrote:
> > We will never make such a commitment, at least not in the foreseeable
> > future.
>
> Here's the problem. If you have a database that is in service, you can
> not upgrade postgres on that machine without taking it out of service
> for the duration of a backup/restore. A small database is not a big
> deal, a large database is a problem. A system could be out of service
> for hours.
>
> For a mission critical installation, this is really unacceptable.
Cheap solution: replication. Bring up a slave with the
new version. Do the initial sync. Wait for a quiet
time, and switch over (possibly still replicating to
the old one so you can revent the upgrade).
The overhead would be fairly high, but it's a cheap way
to get the required properties, and is easy to revert.
Matthew.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Clift | 2002-02-08 13:29:58 | Re: Why dump/restore to upgrade? |
| Previous Message | Marc G. Fournier | 2002-02-08 13:07:54 | Re: Threaded PosgreSQL server |