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
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 |