Testing 9.0beta3 and pg_upgrade

Поиск
Список
Период
Сортировка
От Thomas Kellerer
Тема Testing 9.0beta3 and pg_upgrade
Дата
Msg-id i1g1ga$bto$1@dough.gmane.org
обсуждение исходный текст
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: Configure Postgres From SQL
Следующее
От: Andrew Bartley
Дата:
Сообщение: Redundant database objects.