pg_upgrade operation failed if table created in --single user mode

From: tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: pg_upgrade operation failed if table created in --single user mode
Date: 2021-12-14 17:57:00
Message-ID: 91ec98ce-248a-6896-144f-312fa344c472@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-12-14 18:15:38 Re: Defining (and possibly skipping) useless VACUUM operations
Previous Message Bruce Momjian 2021-12-14 16:59:50 Re: O(n) tasks cause lengthy startups and checkpoints