Re: pg_dumpall -> by hand without --binary-upgrade or BUG #5690: pg_upgrade fails - Mailing list pgsql-bugs
From | Robert Haas |
---|---|
Subject | Re: pg_dumpall -> by hand without --binary-upgrade or BUG #5690: pg_upgrade fails |
Date | |
Msg-id | AANLkTimY6UKs5eAB1Rens_hji9rGLNtLB-xGcPQnoo2i@mail.gmail.com Whole thread Raw |
In response to | pg_dumpall -> by hand without --binary-upgrade or BUG #5690: pg_upgrade fails (Chris English <sglish@hotmail.com>) |
List | pgsql-bugs |
On Mon, Oct 11, 2010 at 7:09 PM, Chris English <sglish@hotmail.com> wrote: > In my attempts=A0I changed all pg_hba.conf (8.4 & 9.0) to trusted, turned= off > firewall, > followed instructions to shut down db(s) and ran cmd.exe as postgres: > > C:\WINDOWS\system32>pg_upgrade.exe -p 5432 -P 5433 -d "c:/program > files/postgres > ql/8.4/data" -D "c:/program files/postgresql/9.0/data" -b "c:/program > files/post > gresql/8.4/bin" -B "c:/program files/postgresql/9.0/bin" > Performing Consistency Checks > ----------------------------- > Checking old data directory (c:/program files/postgresql/8.4/data)ok > Checking old bin directory (c:/program files/postgresql/8.4/bin)ok > Checking new data directory (c:/program files/postgresql/9.0/data)ok > Checking new bin directory (c:/program files/postgresql/9.0/bin)ok > Checking for reg* system oid user data types =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0ok > Checking for /contrib/isn with bigint-passing mismatch =A0 =A0 =A0ok > Checking for large objects =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0ok > Creating catalog dump =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 Access is > denied. > > There were problems executing ""c:/program > files/postgresql/9.0/bin/pg_dumpall" > --port 5432 --username "postgres" --schema-only --binary-upgrade > > "C:\WINDOWS\s > ystem32/pg_upgrade_dump_all.sql"" > I'm not clear if it picked up the 8.4 -p 5432 and 9.0 -P 5433 > C:\WINDOWS\system32>pg_dumpall.exe --port 5433 username--"postgres" > --schema-onl > y >"c:/windows/system32/pg_upgrade_dump_all.sql" > Access is denied. > C:\WINDOWS\system32>pg_dumpall.exe --port 5433 username--"postgres" > --password " > ********" --schema-only >"c:/windows/system32/pg_upgrade_dump_all.sql" > Access is denied. > C:\WINDOWS\system32>pg_dumpall.exe --port 5433 username--"postgres" > --password * > ****** --schema-only >"c:/windows/system32/pg_upgrade_dump_all.sql" > Access is denied. > C:\WINDOWS\system32>pg_dumpall.exe --port 5432 username--"postgres" > --password * > ****** --schema-only >"c:/windows/system32/pg_upgrade_dump_all.sql" > Access is denied. > C:\WINDOWS\system32>pg_dumpall.exe --port 5432 username--"postgres" > --password * > ******* --schema-only >"c:/windows/system32/pg_upgrade_dump_all.sql" > Access is denied. > 8.4 Log > 2010-10-11 18:14:28 EDTLOG: =A0database system was shut down at 2010-10-11 > 17:59:17 EDT > 2010-10-11 18:14:29 EDTLOG: =A0database system is ready to accept connect= ions > 2010-10-11 18:14:35 EDTLOG: =A0received fast shutdown request > 2010-10-11 18:14:35 EDTLOG: =A0aborting any active transactions > 2010-10-11 18:14:35 EDTLOG: =A0shutting down > 2010-10-11 18:14:35 EDTLOG: =A0database system is shut down > 9.0 Log > 2010-10-11 17:14:18 EDT LOG: =A0database system was shut down at 2010-10-= 11 > 16:25:16 EDT > 2010-10-11 17:14:18 EDT FATAL: =A0the database system is starting up > 2010-10-11 17:14:19 EDT LOG: =A0database system is ready to accept connec= tions > 2010-10-11 17:14:19 EDT LOG: =A0autovacuum launcher started > 2010-10-11 17:34:58 EDT LOG: =A0received fast shutdown request > 2010-10-11 17:34:58 EDT LOG: =A0aborting any active transactions > 2010-10-11 17:34:58 EDT LOG: =A0autovacuum launcher shutting down > 2010-10-11 17:34:58 EDT LOG: =A0shutting down > 2010-10-11 17:34:58 EDT LOG: =A0database system is shut down > And there we sit, dejected. =A0Any thoughts would be greatly appreciated. > Chris English Is there any way we can crank up the debug level during those 20 minutes the new database is up? Or look at pg_stat_activity? What is it doing during all that time? --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
pgsql-bugs by date: