public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Nikhil Shetty <[email protected]>
Cc: Laurenz Albe <[email protected]>
Cc: Pgsql-admin <[email protected]>
Subject: Re: pg_upgrade failure due to dependencies
Date: Tue, 01 Jul 2025 13:07:26 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAFpL5VwgA2ae3c3pvTy=-PKfpa-BxmbrmF+ryux2HdJkhRPxOA@mail.gmail.com>
References: <CAFpL5Vw+EK4UN6mHXRqZU+WLyFiSLqPiDAZnA3VX65tNFpyPyA@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAFpL5VwgA2ae3c3pvTy=-PKfpa-BxmbrmF+ryux2HdJkhRPxOA@mail.gmail.com>
Nikhil Shetty <[email protected]> writes:
> Yes both the extension and function are created by the extension but when
> restoring, extension and associated functions or tables are created
> separately and in different order .
Ah, right, I'd momentarily forgotten that binary-upgrade mode dumps
the extensions' contents as separate objects.
I think that switching the function(s) to new-style syntax, as already
mentioned, might get you pretty far. It'd be enough for pg_dump to get
the function-vs-spatial_ref_sys-existence ordering right at least.
What it will not do is ensure that the *contents* of spatial_ref_sys
are restored early. But I'm not sure that that's fatal in a
binary-upgrade situation, because we're not dumping/restoring data:
the tables' disk files are just moved verbatim. There might still be
some edge cases that fail, but I think basic scenarios ought to work.
regards, tom lane
view thread (8+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: pg_upgrade failure due to dependencies
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox