Re: Error pg_upgrade version 11 to 15

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "IVAN HUMANES CABANAS (Fujitsu)" <ivan(dot)humanescabanas(at)fujitsu(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Error pg_upgrade version 11 to 15
Date: 2025-08-18 20:07:01
Message-ID: aKOH5RSGXz0DcU7l@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2025-08-18 20:18:56 Re: Error pg_upgrade version 11 to 15
Previous Message Andrew Dunstan 2025-08-18 19:16:46 Re: Error pg_upgrade version 11 to 15