From: | "Nitin Verma" <nitinverma(at)azulsystems(dot)com> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: VACUUMing sometimes increasing database size / sometimes |
Date: | 2006-06-16 12:04:50 |
Message-ID: | 640150C1BB635E4C9F2F617BA3EFF1D10123E774@XCHMTV1.azulsystems.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>> if your application depends on things that changed between 7.3 and 8.1. >>
Postgres tends to become more strict with every release, so
>> there are things you got away with in 7.3 which now cause an error
>> message.
Do we have change lists where I can see all the changes between 7.3 and 8.1,
may be release by release?
-----Original Message-----
From: Florian G. Pflug [mailto:fgp(at)phlo(dot)org]
Sent: Friday, June 16, 2006 4:48 PM
To: Douglas McNaught
Cc: Nitin Verma; Jim Nasby; pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] VACUUMing sometimes increasing database size /
sometimes
Douglas McNaught wrote:
> "Nitin Verma" <nitinverma(at)azulsystems(dot)com> writes:
>
>> Will 7.3.2 Dump made up of copies using pg_dump import without any
migration
>> to 8.0+? What I need isn't a once process and will go as a automated
script,
>> in a way that user will not even get to know (if he isn't reading that
logs)
>> Database version changed. Considering that even a remote problem in export
>> and import across versions may hit. So please let me know all the do's and
>> don'ts... or the pointers to those.
>
> It will very likely have problems. The usual recommended procedure is
> to use the version of pg_dump that comes with the PG that you're
> upgrading *to* against the old database; e.g. you'd use the 8.0+
> pg_dump and tell it to connect to the 7.3.2 database.
Note that even if your 7.3 dump restores fine on 8.1 (How likely that is
depends on the complexity of your schema), you might still experience
problems, if your application depends on things that changed between 7.3
and 8.1. Postgres tends to become more strict with every release, so
there are things you got away with in 7.3 which now cause an error message.
So, you shouldn't upgrade database version "behind a users back". You'll
need to test his applikations against the new version, or at least tell
him that there might be problems.
> You should really upgrade from 7.3.2, at least to the latest point
> release in the 7.3 series, and have a plan to go to 8.0 or 8.1,
> because 7.3 won't be supported for that much longer (if it even is
> right now).
If 8.0 or 8.1 is too big a step for you, you could consider moving to
7.4. I don't know if 7.3 already supported schemas, but if it did, then
the chance of breakage is a lot smaller if you switch to 7.4 compared to
switching to 8.1. OTOH, one day 7.4 will be unsupported too, and then
you'll need to switch anyway.
greetings, Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2006-06-16 12:19:31 | Re: minimizing downtime when upgrading |
Previous Message | Oleg Bartunov | 2006-06-16 11:52:27 | Re: minimizing downtime when upgrading |