On 2025-08-18 Mo 12:10 PM, Tom Lane wrote:
"IVAN HUMANES CABANAS (Fujitsu)" <ivan.humanescabanas@fujitsu.com> writes:
command: "/usr/pgsql-15/bin/pg_restore" --host /var/lib/pgsql/15/data --port 50432 --username postgres --clean --create --exit-on-error --verbose --dbname postgres "/var/lib/pgsql/15/data/pg_upgrade_output.d/20250818T162430.400/dump/pg_upgrade_dump_18344416.custom" >> "/var/lib/pgsql/15/data/pg_upgrade_output.d/20250818T162430.400/log/pg_upgrade_dump_18344416.log" 2>&1
pg_restore: connecting to database for restore
pg_restore: dropping DATABASE PROPERTIES template1
pg_restore: dropping DATABASE template1
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 3677; 1262 18344416 DATABASE template1 postgres
pg_restore: error: could not execute query: ERROR: cannot drop a template database
Command was: DROP DATABASE "template1";
Hm. The restore should have issued a command to make template1 not be
a template database before dropping it. Apparently it did not do so.
Looking at the code, a plausible theory for that is that template1
is not marked as a template database in the source cluster. Did you
change that, and if so why? It would have broken more things than
just pg_upgrade.
Template1 normally has an OID of 1, but this database has an apparent OID of 18344416. Maybe this has been the result of a previous upgrade - we don't have enough information. I don't think pg_upgrade attempts to preserve database OIDs.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
