I'm trying to test the Postgresql 9.3 -> 9.4 upgrade process on the development environment on windows and I get weird issue during the pg_upgrade invocation:
PS D:\bin\postgres-9.4> .\bin\pg_upgrade.exe -b ..\postgres-9.3\bin\ -B .\bin -d ..\postgres-9.3\data -D .\data -c -v -U postgres
Running in verbose mode
Running in verbose mode
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
pg_control values:
First log segment after reset: 000000010000000000000061
pg_control version number: 937
Catalog version number: 201306121
Database system identifier: 6153485438384190463
Latest checkpoint's TimeLineID: 1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0/1920
Latest checkpoint's NextOID: 19276
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0
Latest checkpoint's oldestXID: 667
Latest checkpoint's oldestXID's DB: 1
Latest checkpoint's oldestActiveXID: 0
Latest checkpoint's oldestMultiXid: 1
Latest checkpoint's oldestMulti's DB: 1
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 131072
WAL block size: 8192
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum columns in an index: 32
Maximum size of a TOAST chunk: 1996
Date/time type storage: 64-bit integers
Float4 argument passing: by value
Float8 argument passing: by reference
Data page checksum version: 0
Current pg_control values:
pg_control version number: 942
Catalog version number: 201409291
Database system identifier: 6155476934462898984
Latest checkpoint's TimeLineID: 1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0/677
Latest checkpoint's NextOID: 12136
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0
Latest checkpoint's oldestXID: 667
Latest checkpoint's oldestXID's DB: 1
Latest checkpoint's oldestActiveXID: 0
Latest checkpoint's oldestMultiXid: 1
Latest checkpoint's oldestMulti's DB: 1
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 131072
WAL block size: 8192
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum columns in an index: 32
Maximum size of a TOAST chunk: 1996
Size of a large-object chunk: 2048
Date/time type storage: 64-bit integers
Float4 argument passing: by value
Float8 argument passing: by reference
Data page checksum version: 0
Values to be changed:
First log segment after reset: 000000010000000000000002
"..\postgres-9.3\bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "..\postgres-9.3\data" -o "-p 50432 -b " start >> "pg_upgrade_server_start.log" 2>&1
executing: SELECT datcollate, datctype FROM pg_catalog.pg_database WHERE datname = 'template0'
executing: SELECT pg_catalog.pg_encoding_to_char(encoding) FROM pg_catalog.pg_database WHERE datname = 'template0'
executing: SELECT c.relname, c.relfilenode FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n WHERE c.relnamespace = n.oid AND n.nspname = 'pg_catalog' AND c.relname = 'pg_database' ORDER BY c.relname
executing: SELECT d.oid, d.datname, pg_catalog.pg_tablespace_location(t.oid) AS spclocation FROM pg_catalog.pg_databased LEFT OUTER JOIN pg_catalog.pg_tablespace t ON d.dattablespace = t.oid WHERE d.datallowconn = true ORDER BY 2
executing: CREATE TEMPORARY TABLE info_rels (reloid) AS SELECT c.oid FROM pg_catalog.pg_class c JOIN pg_catalog.pg_namespace n ON c.relnamespace = n.oid LEFT OUTER JOIN pg_catalog.pg_index i ON c.oid = i.indexrelid WHERE relkind IN ('r', 'm', 'i', 'S') AND i.indisvalid IS DISTINCT FROM false AND i.indisready IS DISTINCT FROM false AND ((n.nspname !~ '^pg_temp_' AND n.nspname !~ '^pg_toast_temp_' AND n.nspname NOT IN ('pg_catalog', 'information_schema', 'binary_upgrade', 'pg_toast') AND c.oid >= 16384) OR (n.nspname = 'pg_catalog' AND relname IN ('pg_largeobject', 'pg_largeobject_loid_pn_index', 'pg_largeobject_metadata', 'pg_largeobject_metadata_oid_index') ));
SQL command failed
CREATE TEMPORARY TABLE info_rels (reloid) AS SELECT c.oid FROM pg_catalog.pg_class c JOIN pg_catalog.pg_namespace n ON c.relnamespace = n.oid LEFT OUTER JOIN pg_catalog.pg_index i ON c.oid = i.indexrelid WHERE relkind IN ('r', 'm', 'i', 'S') AND i.indisvalid IS DISTINCT FROM false AND i.indisready IS DISTINCT FROM false AND ((n.nspname !~'^pg_temp_' AND n.nspname !~ '^pg_toast_temp_' AND n.nspname NOT IN ('pg_catalog', 'information_schema', 'binary_upgrade', 'pg_toast') AND c.oid >= 16384) OR (n.nspname = 'pg_catalog' AND relname IN ('pg_largeobject', 'pg_largeobject_loid_pn_index', 'pg_largeobject_metadata', 'pg_largeobject_metadata_oid_index') ));
ERROR: could not open relation with OID 25370
Failure, exiting
"..\postgres-9.3\bin/pg_ctl" -w -D "..\postgres-9.3\data" -o "" -m fast stop >> "pg_upgrade_utility.log" 2>&1
Both clusters (old and new one were shut down properly and I can start them without any issues in logs. If I do backup/restore of the databases into a new postgresql 9.3 cluster the process finishes successfully, but it is a bad solution if it would happen on the production environment. What could be the problem and what should I do to prevent this issue from happening again?
Thanks!
Small update: there're no records with OID 25370 in any system tables and no files/folder in the cluster directory with this name.
