Date: Mon, 18 Aug 2025 15:07:01 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
	"IVAN HUMANES CABANAS (Fujitsu)" <ivan.humanescabanas@fujitsu.com>,
	"pgsql-bugs@postgresql.org" <pgsql-bugs@postgresql.org>
Subject: Re: Error pg_upgrade version 11 to 15
Message-ID: <aKOH5RSGXz0DcU7l@nathan>
References: 
 <AMBP191MB2746B1A4B24D87330C7A028DFD31A@AMBP191MB2746.EURP191.PROD.OUTLOOK.COM>
 <417487.1755533405@sss.pgh.pa.us>
 <6545b4ca-a685-4a30-8aec-451dcb891d0b@dunslane.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6545b4ca-a685-4a30-8aec-451dcb891d0b@dunslane.net>
Archived-At: <https://www.postgresql.org/message-id/aKOH5RSGXz0DcU7l%40nathan>
Precedence: bulk

On Mon, Aug 18, 2025 at 03:16:46PM -0400, Andrew Dunstan wrote:
> 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.

It does as of v15 [0].

I concur with Tom that this is most likely due to template1 not being
marked as a template database in the source cluster.  We could presumably
hack pg_upgrade to deal with this for template1 and postgres databases
(e.g., by preemptively setting datistemplate = f on the new cluster).
Changes to template0 are likely harder to deal with.  Since pg_dump uses it
as the template for databases it creates, we'd have to wait until all other
databases are restored before re-creating it.  Plus, we'd probably have to
first create a fresh template0 clone (with the source template0's encoding
and locale settings) so that there was something to use as a template for
template0.  There might be other problems, and I'm not sure it's worth the
effort, anyway.

[0] https://postgr.es/c/aa01051

-- 
nathan