pg_upgrade operation failed if table created in --single user mode - Mailing list pgsql-hackers

From tushar
Subject pg_upgrade operation failed if table created in --single user mode
Date
Msg-id 91ec98ce-248a-6896-144f-312fa344c472@enterprisedb.com
Whole thread Raw
Responses Re: pg_upgrade operation failed if table created in --single user mode
List pgsql-hackers
Hi,

Please refer to this scenario where pg_upgrade operation is failing if 
the table is create in single-user mode.

PG v13
--connect to PG v13 using single user mode  ( ./postgres --single -D 
/tmp/data13 postgres )
--create table ( backend> create table r(n int); )
--exit  ( ctrl + D)

-- Perform pg_upgrade ( PG v13->PG v15)  )(./pg_upgrade -d data13 -D 
data15 -b /usr/psql-12/bin -B . )

it will fail with these messages

Restoring global objects in the new cluster                 ok
Restoring database schemas in the new cluster
   postgres
*failure*

Consult the last few lines of "pg_upgrade_dump_14174.log" for
the probable cause of the failure.
Failure, exiting

--cat pg_upgrade_dump_14174.log
--
--
--
--
pg_restore: creating TABLE "public.r"
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 200; 1259 14180 TABLE r edb
pg_restore: error: could not execute query: ERROR:  pg_type array OID 
value not set when in binary upgrade mode
Command was:
-- For binary upgrade, must preserve pg_type oid
SELECT 
pg_catalog.binary_upgrade_set_next_pg_type_oid('14181'::pg_catalog.oid);


-- For binary upgrade, must preserve pg_class oids and relfilenodes
SELECT 
pg_catalog.binary_upgrade_set_next_heap_pg_class_oid('14180'::pg_catalog.oid);
SELECT 
pg_catalog.binary_upgrade_set_next_heap_relfilenode('14180'::pg_catalog.oid);

CREATE TABLE "public"."r" (
     "n" integer
);

-- For binary upgrade, set heap's relfrozenxid and relminmxid
UPDATE pg_catalog.pg_class
SET relfrozenxid = '492', relminmxid = '1'
WHERE oid = '"public"."r"'::pg_catalog.regclass;

Is it expected ?

-- 
regards,tushar
EnterpriseDB  https://www.enterprisedb.com/
The Enterprise PostgreSQL Company




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: O(n) tasks cause lengthy startups and checkpoints
Next
From: Peter Geoghegan
Date:
Subject: Re: Defining (and possibly skipping) useless VACUUM operations