| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, "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 21:53:50 |
| Message-ID: | aKOg7rIY3G94asHn@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2025-08-19 00:07:23 | Re: Potential deadlock in pgaio_io_wait() |
| Previous Message | Tom Lane | 2025-08-18 20:18:56 | Re: Error pg_upgrade version 11 to 15 |