Testing 9.0beta3 and pg_upgrade - Mailing list pgsql-general

From Thomas Kellerer
Subject Testing 9.0beta3 and pg_upgrade
Date
Msg-id i1g1ga$bto$1@dough.gmane.org
Whole thread Raw
Responses Re: Testing 9.0beta3 and pg_upgrade  (Craig Ringer <craig@postnewspapers.com.au>)
Re: Testing 9.0beta3 and pg_upgrade  (Thomas Kellerer <spam_eater@gmx.net>)
Re: Testing 9.0beta3 and pg_upgrade  (Thomas Kellerer <spam_eater@gmx.net>)
Re: Testing 9.0beta3 and pg_upgrade  (Bruce Momjian <bruce@momjian.us>)
List pgsql-general
Hi,

I'm trying pg_upgrade on my Windows installation and I have two suggestions  for the manual regarding pg_upgrade:

When specifying directories, pg_upgrade *requires* a forward slash as the path separator. This is (still) uncommon in
theWindows world (although Windows does support it) and even though the example in the manual does show forward
slashes,I think it would be a good idea to specifically mention the fact that it will *not* work with a backslash. 

Actually the error message when you do so is a bit misleading as well ("You must identify the directory where the old
clusterbinaries reside") even though the paramter is there. 

After I sorted that out I ran pg_upgrade and it failed somewhere in the middle:

------ snip

C:\etc\pg90-beta3>C:\etc\pg90-beta3\pgsql\bin\pg_upgrade.exe         --user=postgres         --old-datadir
"c:/Daten/db/pgdata84/"        - 
-old-bindir "c:/Programme/PostgreSQL/8.4/bin/"         --new-datadir "c:/etc/pg90-beta3/datadir/"
--new-port=5434        --new-bind 
ir "C:\etc\pg90-beta3\pgsql\bin"

Performing Consistency Checks
-----------------------------
Checking old data directory (c:/Daten/db/pgdata84)          ok
Checking new data directory (c:/etc/pg90-beta3/datadir)     ok
Checking for /contrib/isn with bigint-passing mismatch      ok
Checking for large objects                                  ok
Creating catalog dump                                       ok
Checking for presence of required libraries                 ok

| If pg_upgrade fails after this point, you must
| re-initdb the new cluster before continuing.
| You will also need to remove the ".old" suffix
| from c:/Daten/db/pgdata84/global/pg_control.old.

Performing Migration
--------------------
Adding ".old" suffix to old global/pg_control               ok
Analyzing all rows in the new cluster                       ok
Freezing all rows on the new cluster                        ok
Deleting new commit clogs                                   ok
Copying old commit clogs to new server                      1 Datei(en) kopiert
ok
Setting next transaction id for new cluster                 ok
Resetting WAL archives                                      ok
Setting frozenxid counters in new cluster                   ok
Creating databases in the new cluster                       psql:C:/etc/pg90-beta3/pg_upgrade_dump_globals.sql:29:
ERROR: CREATE DATABASE c 
annot run inside a transaction block

There were problems executing ""C:\etc\pg90-beta3\pgsql\bin/psql" --port 5434 --username "postgres" --set
ON_ERROR_STOP=on-f "C:\etc\pg90-b 
eta3/pg_upgrade_dump_globals.sql" --dbname template1 >> "nul""

------ end of console output --------

The "cannot run inside a transaction block" rang a bell, and once I removed "\set AUTOCOMMIT off" from my psqlrc.conf,
pg_upgradewent through without problems. 

I would suggest to either manually change the autocommit mode from within pg_upgrade or to add a note in the manual to
disable/removethis setting from psqlrc.conf before running pg_upgrade. Personally I think the first option would be the
betterone. 

Regards
Thomas





pgsql-general by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: Configure Postgres From SQL
Next
From: Andrew Bartley
Date:
Subject: Redundant database objects.