From: | Thom Brown <thombrown(at)gmail(dot)com> |
---|---|
To: | pgsql general <pgsql-general(at)postgresql(dot)org> |
Subject: | Automatic database upgrade |
Date: | 2009-02-05 09:49:38 |
Message-ID: | bddc86150902050149o7257c328me43d3db8729954e1@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
I've got a question which I hope you'll forgive if I'm missing something
obvious...
We (you, me, everyone) are currently presented with a problem when upgrading
our installed version of PostgreSQL when upgrading to a major release
version (i.e. 8.2 to 8.3, or 8.3 to 8.4) Is it not possible to have
PostgreSQL "upgrade" the actual database cluster upon installing a new major
version? I don't mean as a step during the actual upgrade. I'm suggesting
that, if the database cluster has some sort of attribute which Postgres
could read which would identify the latest version it was running against,
then a tool (let's call it pg_upgrade) runs against that cluster to make it
work against the newly installed version. I'm not sure if it would perform
a dump then a restore, or whether it would actually change the data in the
cluster (sounds dangerous).
I only ask this as it seems weird to have up dump everything, then restore
it all again manually. I'm not sure other RBDMS require the user to perform
these manual steps Postgres requires. Actually, it might go down as a pet
peeve.
Is such a thing feasible? Or is there a better solution?
Maybe this is probably because I am not familiar enough with dumping and
restoring clusters.
Cheers
Thom
From | Date | Subject | |
---|---|---|---|
Next Message | Nico Callewaert | 2009-02-05 10:01:21 | Re: Elapsed time between timestamp variables in Function |
Previous Message | Sebastian Tennant | 2009-02-05 08:12:48 | Re: running postgres |