From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: Andrew Dunstan <andrew@dunslane.net>,
        "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
In-reply-to: <aKOH5RSGXz0DcU7l@nathan>
References: 
 <AMBP191MB2746B1A4B24D87330C7A028DFD31A@AMBP191MB2746.EURP191.PROD.OUTLOOK.COM>
 <417487.1755533405@sss.pgh.pa.us>
 <6545b4ca-a685-4a30-8aec-451dcb891d0b@dunslane.net> <aKOH5RSGXz0DcU7l@nathan>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Mon, 18 Aug 2025 15:07:01 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <454617.1755548336.1@sss.pgh.pa.us>
Date: Mon, 18 Aug 2025 16:18:56 -0400
Message-ID: <454618.1755548336@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/454618.1755548336%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> 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.

Yeah.  The logic about this is in pg_dump, actually: dumpDatabase()
decides whether or not to add "UPDATE ... SET datistemplate = false"
to the delQry.  I was thinking about having it do that either if
the source DB has datistemplate or if its name is template1.
That would cover both (1) restoring a nonstandard set of databases
into the original installation with --clean, and (2) restoring a
nonstandard setup into a pristine installation.  I don't think we
need to account for template0 because neither pg_dumpall nor
pg_upgrade will attempt to replace it.

However, first I'd like confirmation that this theory explains
the OP's problem.

			regards, tom lane