Thread: migration of 7.4 to 8.1

sathiya psql wrote:
> Is there any article describing the migration database from postgresql 7.4to
> 8.1
This might be a silly question, but ... why 8.1 ?

If you're doing a major upgrade, why not go straight to 8.3? It's been
out long enough that there aren't any obvious nasty bugs, and there have
been a fair few fixes and improvements since prior versions.

--
Craig Ringer

sathiya psql wrote:
>     This might be a silly question, but ... why 8.1 ?
>
>     If you're doing a major upgrade, why not go straight to 8.3? It's been
>     out long enough that there aren't any obvious nasty bugs, and there have
>     been a fair few fixes and improvements since prior versions.
>
> Because am using Debian ETCH stable... i need to continue using this...
> In Debian ETCH stable 8.1 is only there....
>
> I will be installing my project in other machines where it is having
> DEBIAN ETCH STABLE, i dont want to face any problems... so only...

You can get 8.3 from backports: http://www.backports.org/ - it's a
debian project to get more up to date versions for existing stable
releases (they package everything exactly the same way).

--
Postgresql & php tutorials
http://www.designmagick.com/

sathiya psql wrote:
>> This might be a silly question, but ... why 8.1 ?
>>
>> If you're doing a major upgrade, why not go straight to 8.3? It's been
>> out long enough that there aren't any obvious nasty bugs, and there have
>> been a fair few fixes and improvements since prior versions.
>>
> Because am using Debian ETCH stable... i need to continue using this... In
> Debian ETCH stable 8.1 is only there....

I use Etch on my servers. The magic of etch-backports from backports.org
allows me to use 8.3 without messing with anything else. It works
extremely well.

All I had to do to install 8.3 was add the etch-backports line to my
/etc/apt/sources.list, run `apt-get update', then run:

apt-get -t etch-backports install postgresql-8.3

... then migrate the data to it and remove the old packages.

See backports.org for a mirror list.

> I will be installing my project in other machines where it is having DEBIAN
> ETCH STABLE, i dont want to face any problems... so only...
>
> am i right ???

Personally I'd use 8.3 from backports.org, but it's of course up to you.

--
Craig Ringer

sathiya psql wrote:
>> This might be a silly question, but ... why 8.1 ?
>>
>
> how it will be a silly question....
>
> I thought that some manual changes are required... so am asking this.... may
> be argument for functions had changed.. or any other changes...
There have been changes for sure... but I doubt going from 7.4 to 8.1 is
much harder than going from 7.4 to 8.3 . I'm developing a database that
started off in 8.1 just before 8.2 came out and is now running on 8.3 .
I didn't find changing versions a big hassle and noticed big
improvements between versions.

In any case, I was suggesting that *I* might've been asknig a silly
question by asking you why you wanted 8.1. You've covered that (you want
to use the version packaged in your distro) so that's easy enough.

--
Craig Ringer

On Wed, 12 Mar 2008, sathiya psql wrote:

> My question is that how to migrate my database to 7.4 to 8.1
>
>
> that is not only dumping the db and extracting that in 8.1 ..
>
> If i do that whether it will work without problem, or i have to do some
> manual changes is my question...

you would need to look at the release notes for each version to see if you
are using any of the features that were changed.

but in return for this hassle (which you will need to do eventually, you
are just deciding when) you get to use the newer version with all the
speed improvements, not to mention the new features.

going from 7.x to 8.0 is the most painful step. going on from 8.0 to 8.1
to 8.2 to 8.3 are relativly minor steps in comparison.

David Lang

sathiya psql wrote:
> My question is that how to migrate my database to 7.4 to 8.1
>
>
> that is not only dumping the db and extracting that in 8.1 ..
>
> If i do that whether it will work without problem, or i have to do some
> manual changes is my question...

Start by reading the postgresql 8.0 and 8.1 release notes. See:

http://www.postgresql.org/docs/current/static/release.html

particularly:

http://www.postgresql.org/docs/current/static/release-8-0.html
http://www.postgresql.org/docs/current/static/release-8-1.html

--
Craig Ringer

On Wed, 12 Mar 2008, Craig Ringer wrote:

> sathiya psql wrote:
>>> This might be a silly question, but ... why 8.1 ?
>>>
>>> If you're doing a major upgrade, why not go straight to 8.3? It's been
>>> out long enough that there aren't any obvious nasty bugs, and there have
>>> been a fair few fixes and improvements since prior versions.
>>>
>> Because am using Debian ETCH stable... i need to continue using this... In
>> Debian ETCH stable 8.1 is only there....
>
> I use Etch on my servers. The magic of etch-backports from backports.org
> allows me to use 8.3 without messing with anything else. It works extremely
> well.
>
> All I had to do to install 8.3 was add the etch-backports line to my
> /etc/apt/sources.list, run `apt-get update', then run:
>
> apt-get -t etch-backports install postgresql-8.3
>
> ... then migrate the data to it and remove the old packages.
>
> See backports.org for a mirror list.
>
>> I will be installing my project in other machines where it is having DEBIAN
>> ETCH STABLE, i dont want to face any problems... so only...
>>
>> am i right ???
>
> Personally I'd use 8.3 from backports.org, but it's of course up to you.

consider the fact that after 1 year Etch is 2 major releases out of date.
by the time the next stable release is made you will be running on ancient
versions unless you make use of backports.org (or compile it yourself,
which is useually my choice).

David Lang

On Wed, 12 Mar 2008, sathiya psql wrote:

> In the home page itself they were saying .... testing ... unstable....

you are talking about the debian home page right?

> then we should not use that for live.....
>
> so i prefer 8.1 .........

Debian selected the version of Postgres for Etch about a year and a half
ago. At that point selecting 8.1 was a resonable choice.

Debian has a policy that they will never change the version number of a
package in a stable release (they will backport many bugfixes, but not
upgrade the version)

As a result 2 years from now when Postgres is on 8.5 stable (and looking
at 8.6), Debian Etch will still be on 8.1

it is of course your option to stick with 8.1, but before very long the
answer to most of your questions about postgres is going to be 'upgrade to
a resonably current version' (people running 7.4 and 8.0 are starting to
get that answer now. 8.1 and 8.2 are recent enough that it's rare to get
that now, but in a year or two that will change)

for most utility software you just want it to work and don't really care
about new features over a couple of years (or the project has reached the
stage where it just doesn't change much over a couple of years). In these
situations the Debian policy is great, you don't have to worry about new
stuff messing you up.

however some software has much faster development cycles. The kernel has a
new release about every two months, Postgres is aiming at a one year
cycle, Apache has it's own release schedule. These packages are usually
pretty core to your operation and the improvments (and security fixes that
are not possible to backport sanely) mean that you need to think very hard
about what version of them you are going to run. On my systems I bypass
Debian directly for such packages and compile them myself, the
backports.org option allows you to avoid that hassle, and get versions
that are fairly well tested (like any new version, you need to do some
testing yourself), just wait a month or two after a new release hits
backports.org and you will be pretty safe.

David Lang

>>
>> You can get 8.3 from backports: http://www.backports.org/ - it's a
>> debian project to get more up to date versions for existing stable
>> releases (they package everything exactly the same way).
>>
>> --
>> Postgresql & php tutorials
>> http://www.designmagick.com/
>>
>

david@lang.hm wrote:
> On Wed, 12 Mar 2008, sathiya psql wrote:
>
>> In the home page itself they were saying .... testing ... unstable....
>
> you are talking about the debian home page right?
>
>> then we should not use that for live.....
>>
>> so i prefer 8.1 .........
>
> Debian selected the version of Postgres for Etch about a year and a half
> ago. At that point selecting 8.1 was a resonable choice.
>
> Debian has a policy that they will never change the version number of a
> package in a stable release (they will backport many bugfixes, but not
> upgrade the version)
>
> As a result 2 years from now when Postgres is on 8.5 stable (and looking
> at 8.6), Debian Etch will still be on 8.1

I like that with debian I can install multiple postgres versions and it
handles everything for me :) Changing the default port, config files are
in different folders, different start up scripts.. all works very nicely :)

Which means you can have 8.1 installed and 8.3 installed at the same
time - both from packages, no compiling etc necessary - and can switch
between them very easily.

--
Postgresql & php tutorials
http://www.designmagick.com/

On Wed, Mar 12, 2008 at 12:13:01PM +0530, sathiya psql wrote:
> My question is that how to migrate my database to 7.4 to 8.1

  aptitude install postgresql-8.1
  pg_dropcluster 8.1 main
  pg_upgradecluster 7.4 main

/* Steinar */
--
Homepage: http://www.sesse.net/

On Mar 12, 2008, at 2:43 AM, sathiya psql wrote:

> My question is that how to migrate my database to 7.4 to 8.1
>
>
> that is not only dumping the db and extracting that in 8.1 ..
>
> If i do that whether it will work without problem, or i have to do
> some manual changes is my question...

the pg dump/restore should work without issue.  you might not get all
the relations of which sequence is "owned" by which table, and similar
for foreign keys, but you may not miss that much.

then, review *every* SQL query you run and make sure it runs against
8.1.  things that will trap you are treating strings as integers in
certain cases.  most everything else should just work.  you will also
want to review the performance of each query.

you can find a detailed list of changes to the DB in the release notes
file that comes with every release.

finally, this is not really a performance issue, so perhaps the pg-
general list would have been better to ask your question.