Thread: Upgrade/Installation problem: Version 7.4.9 to version 8.1.3

Andrew,

If you're moving between major versions, a dump/restore is necessary.  The
proper procedure is:

1) pg_dump the old database by using the new version of pg_dump (8.1.x)
against the old db server (7.4.9 in your case)
2) stop the old database server (and possibly move/rename the old data dir)
3) initdb the new database server
4) edit postgresql.conf, etc
5) start the new database server
6) pg_restore the old database into the newly initialized data directory

So, it sounds like you'll need to reinstall 7.4 and bring it back up, then use
the 8.1.3 pg_dump to create a dump, then restore that into the new 8.1 server.

On Wed, 17 Jan 2007, Andrew Edson wrote:

> I was requested to load data (a full copy of the db in question) from one postgres database into another (empty) db
onanother system.  Both of these systems are running SuSE 9.2 Linux, for the record.  It turned out that the two
systemswere running different versions of postgres; the first system (the one that needed the data) was running version
7.4.9,while the other system was (and is) running 8.1.3.  I copied the 8.1.3 installation packet over to the first
computer,and tried to install it. 
>
>  Originally, when starting the (supposed) 8.1.3 pg_ctl, I got an error about tcpip_socket.  A search on the postgres
sitelead me to believe I could remedy the problem by uninstalling the older version of postgres.  I proceded in the
followingorder: swap to the installation directory for 8.1.3, make uninstall, make distclean, swap to the 7.4.9
installationdirectory, make uninstall, make distclean, swap back to 8.1.3, configure, make, make install.  I still got
theerror, though.  I finally found it mentioned in the postgres.conf file, and commented out the line.  Next, I was
toldthat my data files were initialized in 7.4, despite my earlier efforts, and after renaming the old folder, I went
backand repeated the steps of (8.1.3)make uninstall, make distclean, configure, make, make install.  However, there is
nodata directory in the base postgres directory now, only the older renamed one. 
>
>  If anyone can tell me what to do to get this system back up and running, I would appreciate it greatly.  If more
informationis needed, I will be happy to supply as much as I can. 
>
>  Thank you for your consideration.
>
>
> ---------------------------------
> Access over 1 million songs - Yahoo! Music Unlimited.

--
Jeff Frost, Owner     <jeff@frostconsultingllc.com>
Frost Consulting, LLC     http://www.frostconsultingllc.com/
Phone: 650-780-7908    FAX: 650-649-1954

Andrew,

If you're moving between major versions, a dump/restore is necessary. The
proper procedure is:

1) pg_dump the old database by using the new version of pg_dump (8.1.x)
against the old db server (7.4.9 in your case)
2) stop the old database server (and possibly move/rename the old data dir)
3) initdb the new database server
4) edit postgresql.conf, etc
5) start the new database server
6) pg_restore the old database into the newly initialized data directory

So, it sounds like you'll need to reinstall 7.4 and bring it back up, then use
the 8.1.3 pg_dump to create a dump, then restore that into the new 8.1 server.

You have to dump the original 7.4.9 version of the database and restore that
into the 8.1.3 database server.

An example:

I have a server db1 which is running pg 7.4.9
I have a server db2 which is to replace db1 running pg 8.1.3

I would likely just do something like this from db2 (assuming no clients are
writing to db1 while this is happening):

pg_dumpall -h db1 | psql -h db2


On Wed, 17 Jan 2007, Andrew Edson wrote:

> Please clear something up for me.  The database I'm trying to upgrade was/is empty; only the original installation
waspresent, no tables.  Exactly what is it I'm supposed to be dumping?  If you mean making a copy of the original
8.1.3,that I've done before, but I'm unclear as to the meaning of what you're saying at the moment.  Please enlighten
me.
>
> Jeff Frost <jeff@frostconsultingllc.com> wrote:   Andrew,
>
> If you're moving between major versions, a dump/restore is necessary. The
> proper procedure is:
>
> 1) pg_dump the old database by using the new version of pg_dump (8.1.x)
> against the old db server (7.4.9 in your case)
> 2) stop the old database server (and possibly move/rename the old data dir)
> 3) initdb the new database server
> 4) edit postgresql.conf, etc
> 5) start the new database server
> 6) pg_restore the old database into the newly initialized data directory
>
> So, it sounds like you'll need to reinstall 7.4 and bring it back up, then use
> the 8.1.3 pg_dump to create a dump, then restore that into the new 8.1 server.
>
>
> ---------------------------------
> It's here! Your new message!
> Get new email alerts with the free Yahoo! Toolbar.

--
Jeff Frost, Owner     <jeff@frostconsultingllc.com>
Frost Consulting, LLC     http://www.frostconsultingllc.com/
Phone: 650-780-7908    FAX: 650-649-1954

And of course, I should have made mention of the docs here:
http://www.postgresql.org/docs/8.1/interactive/migration.html

because it likely explains it better than I am. :-)

On Wed, 17 Jan 2007, Jeff Frost wrote:

> You have to dump the original 7.4.9 version of the database and restore that
> into the 8.1.3 database server.
>
> An example:
>
> I have a server db1 which is running pg 7.4.9
> I have a server db2 which is to replace db1 running pg 8.1.3
>
> I would likely just do something like this from db2 (assuming no clients are
> writing to db1 while this is happening):
>
> pg_dumpall -h db1 | psql -h db2
>
>
> On Wed, 17 Jan 2007, Andrew Edson wrote:
>
>> Please clear something up for me.  The database I'm trying to upgrade
>> was/is empty; only the original installation was present, no tables.
>> Exactly what is it I'm supposed to be dumping?  If you mean making a copy
>> of the original 8.1.3, that I've done before, but I'm unclear as to the
>> meaning of what you're saying at the moment.  Please enlighten me.
>>
>> Jeff Frost <jeff@frostconsultingllc.com> wrote:   Andrew,
>>
>> If you're moving between major versions, a dump/restore is necessary. The
>> proper procedure is:
>>
>> 1) pg_dump the old database by using the new version of pg_dump (8.1.x)
>> against the old db server (7.4.9 in your case)
>> 2) stop the old database server (and possibly move/rename the old data dir)
>> 3) initdb the new database server
>> 4) edit postgresql.conf, etc
>> 5) start the new database server
>> 6) pg_restore the old database into the newly initialized data directory
>>
>> So, it sounds like you'll need to reinstall 7.4 and bring it back up, then
>> use
>> the 8.1.3 pg_dump to create a dump, then restore that into the new 8.1
>> server.
>>
>>
>> ---------------------------------
>> It's here! Your new message!
>> Get new email alerts with the free Yahoo! Toolbar.
>
>

--
Jeff Frost, Owner     <jeff@frostconsultingllc.com>
Frost Consulting, LLC     http://www.frostconsultingllc.com/
Phone: 650-780-7908    FAX: 650-649-1954

1. Curious about the difference in step 6 of this list, uses pg_restore, and what is listed in the doc:
     http://www.postgresql.org/docs/8.2/interactive/install-upgrading.html
   which says to restore via:
     psql -d postgres -f outputfile

Is this use of psql related to the fact that a pg_dumpall was the starting place instead
of pg_dump as is used in this list of steps?  Can you use psql -f to restore a backup
via pg_dump?

2.  Also, I found myself wondering:
    pg_dump -> pg_restore
    pg_dumpall -> ?

I would have expected a pg_restoreall.  Also, I would expect such a
pg_restoreall to do the initdb step in the process of restoring "all."
Why is there pg_dumpall instead of a pg_dump with some flag?





On Wed, Jan 17, 2007 at 12:41:55PM -0800, Andrew Edson wrote:
> Please clear something up for me.  The database I'm trying to upgrade was/is empty; only the original installation
waspresent, no tables.  Exactly what is it I'm supposed to be dumping?  If you mean making a copy of the original
8.1.3,that I've done before, but I'm unclear as to the meaning of what you're saying at the moment.  Please enlighten
me.
>
> Jeff Frost <jeff@frostconsultingllc.com> wrote:   Andrew,
>
> If you're moving between major versions, a dump/restore is necessary. The
> proper procedure is:
>
> 1) pg_dump the old database by using the new version of pg_dump (8.1.x)
> against the old db server (7.4.9 in your case)
> 2) stop the old database server (and possibly move/rename the old data dir)
> 3) initdb the new database server
> 4) edit postgresql.conf, etc
> 5) start the new database server
> 6) pg_restore the old database into the newly initialized data directory
>
> So, it sounds like you'll need to reinstall 7.4 and bring it back up, then use
> the 8.1.3 pg_dump to create a dump, then restore that into the new 8.1 server.
>
>
> ---------------------------------
> It's here! Your new message!
> Get new email alerts with the free Yahoo! Toolbar.
--
You have no chance to survive make your time.

On Wed, 17 Jan 2007, Ray Stell wrote:

>
> 1. Curious about the difference in step 6 of this list, uses pg_restore, and what is listed in the doc:
>     http://www.postgresql.org/docs/8.2/interactive/install-upgrading.html
>   which says to restore via:
>     psql -d postgres -f outputfile
>

It depends on the output format.  Pg_restore is used if you created the dump
file in one of the non-text formats (such as -Fc or -Ft).


> Is this use of psql related to the fact that a pg_dumpall was the starting place instead
> of pg_dump as is used in this list of steps?  Can you use psql -f to restore a backup
> via pg_dump?
>
> 2.  Also, I found myself wondering:
>    pg_dump -> pg_restore
>    pg_dumpall -> ?

pg_dumpall creates plain text sql scripts (like the default output for
pg_dump), so it's:

pg_dumpall -> psql

>
> I would have expected a pg_restoreall.  Also, I would expect such a
> pg_restoreall to do the initdb step in the process of restoring "all."
> Why is there pg_dumpall instead of a pg_dump with some flag?

pg_dumpall does all DBs plus the globals, but I'll have to let one of the
developers answer why there isn't just a flag for pg_dump.

>
>
>
>
>
> On Wed, Jan 17, 2007 at 12:41:55PM -0800, Andrew Edson wrote:
>> Please clear something up for me.  The database I'm trying to upgrade was/is empty; only the original installation
waspresent, no tables.  Exactly what is it I'm supposed to be dumping?  If you mean making a copy of the original
8.1.3,that I've done before, but I'm unclear as to the meaning of what you're saying at the moment.  Please enlighten
me.
>>
>> Jeff Frost <jeff@frostconsultingllc.com> wrote:   Andrew,
>>
>> If you're moving between major versions, a dump/restore is necessary. The
>> proper procedure is:
>>
>> 1) pg_dump the old database by using the new version of pg_dump (8.1.x)
>> against the old db server (7.4.9 in your case)
>> 2) stop the old database server (and possibly move/rename the old data dir)
>> 3) initdb the new database server
>> 4) edit postgresql.conf, etc
>> 5) start the new database server
>> 6) pg_restore the old database into the newly initialized data directory
>>
>> So, it sounds like you'll need to reinstall 7.4 and bring it back up, then use
>> the 8.1.3 pg_dump to create a dump, then restore that into the new 8.1 server.
>>
>>
>> ---------------------------------
>> It's here! Your new message!
>> Get new email alerts with the free Yahoo! Toolbar.
>

--
Jeff Frost, Owner     <jeff@frostconsultingllc.com>
Frost Consulting, LLC     http://www.frostconsultingllc.com/
Phone: 650-780-7908    FAX: 650-649-1954

On Wed, Jan 17, 2007 at 01:18:06PM -0800, Jeff Frost wrote:
> On Wed, 17 Jan 2007, Ray Stell wrote:
> >Why is there pg_dumpall instead of a pg_dump with some flag?
>
> pg_dumpall does all DBs plus the globals, but I'll have to let one of the
> developers answer why there isn't just a flag for pg_dump.

Thanks.

If I've done a pg_dumpall does some of the sql that gets included
fail in the restore because the objects already exist via the documented
initdb?  That is how it works with oracle, you export, install a db, then
import, but the import throws errors because of the installe objects already
exist.

On Wed, 17 Jan 2007, Ray Stell wrote:

> On Wed, Jan 17, 2007 at 01:18:06PM -0800, Jeff Frost wrote:
>> On Wed, 17 Jan 2007, Ray Stell wrote:
>>> Why is there pg_dumpall instead of a pg_dump with some flag?
>>
>> pg_dumpall does all DBs plus the globals, but I'll have to let one of the
>> developers answer why there isn't just a flag for pg_dump.
>
> Thanks.
>
> If I've done a pg_dumpall does some of the sql that gets included
> fail in the restore because the objects already exist via the documented
> initdb?  That is how it works with oracle, you export, install a db, then
> import, but the import throws errors because of the installe objects already
> exist.

Yes, for instance the postgres db user is pretty much guaranteed to exist.
Usually when I do a restore, I do it like this:

zcat dumpall.gz | psql postgres > restore.txt 2> restore.err
or
pg_restore frostconsulting.dmp | psql frostconsulting > restore.txt 2> restore.err

and that way I can review the errors in restore.err to determine if it's
a real issue or not.

--
Jeff Frost, Owner     <jeff@frostconsultingllc.com>
Frost Consulting, LLC     http://www.frostconsultingllc.com/
Phone: 650-780-7908    FAX: 650-649-1954

On Wed, Jan 17, 2007 at 01:31:50PM -0800, Jeff Frost wrote:

Please, a couple of more questions about this upgrade process (never been through it, obviously).

1. I am backing up some of the config files that I know that I have touched:

     postgresql.conf, pg_hba.conf

   Are there other files down in there that I will need later that you tend to want to keep?

2. When you prepare to pg_dumpall using the new version, do you need to change all the
   path vars to point to the new install such as LD_LIBRARY_PATH and PATH, or does just
   an explicit call of the new pg_dumpall ok?

Thanks.

Ray Stell <stellr@cns.vt.edu> writes:
> 2. When you prepare to pg_dumpall using the new version, do you need to change all the
>    path vars to point to the new install such as LD_LIBRARY_PATH and PATH, or does just
>    an explicit call of the new pg_dumpall ok?

Just call the new version --- you might need to give it an explicit -P
switch if you compiled it with a different default port number, but
that's about it.

            regards, tom lane