Date: Mon, 18 Aug 2025 16:53:50 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
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
Message-ID: <aKOg7rIY3G94asHn@nathan>
References: 
 <AMBP191MB2746B1A4B24D87330C7A028DFD31A@AMBP191MB2746.EURP191.PROD.OUTLOOK.COM>
 <417487.1755533405@sss.pgh.pa.us>
 <6545b4ca-a685-4a30-8aec-451dcb891d0b@dunslane.net>
 <aKOH5RSGXz0DcU7l@nathan>
 <454618.1755548336@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <454618.1755548336@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/aKOg7rIY3G94asHn%40nathan>
Precedence: bulk

On Mon, Aug 18, 2025 at 04:18:56PM -0400, Tom Lane wrote:
> 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.

WFM, provided your theory is correct.

-- 
nathan