From: Justin Pryzby <pryzby@telsasoft.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: David G. Johnston <david.g.johnston@gmail.com>
Cc: Petr Vejsada <pve@paymorrow.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: pg_upgrade (12->14) fails on aggregate
Date: Fri, 24 Jun 2022 15:28:24 -0500
Message-ID: <20220624202824.GF22452@telsasoft.com> (raw)
In-Reply-To: <33211367-6CAF-4B09-AA0E-020C62FAD8EF@yandex-team.ru>
References: <3383880.QJadu78ljV@vejsadalnx>
<CAKFQuwbUUwkO0ffRY4+z4Hs9-jRjAUwGHZrDKyHhRudWVhtgkw@mail.gmail.com>
<20220614230949.GX29853@telsasoft.com>
<540147.1655321524@sss.pgh.pa.us>
<20220617020103.GG29853@telsasoft.com>
<CA+Tgmob=sKD=Ag3TXQ+b7wWiJaoYaV-AgEddQYCxMNMCqmz=bA@mail.gmail.com>
<1216673.1655475253@sss.pgh.pa.us>
<20220622235845.GV22452@telsasoft.com>
<33211367-6CAF-4B09-AA0E-020C62FAD8EF@yandex-team.ru>
On Fri, Jun 24, 2022 at 11:43:18PM +0500, Andrey Borodin wrote:
> > On 23 Jun 2022, at 04:58, Justin Pryzby <pryzby@telsasoft.com> wrote:
> >
> > On Fri, Jun 17, 2022 at 10:14:13AM -0400, Tom Lane wrote:
> >> Robert Haas <robertmhaas@gmail.com> writes:
> >>> On Thu, Jun 16, 2022 at 10:01 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
> >>>> To me, oid>=16384 seems more hard-wired than namespace!='pg_catalog'.
> >>
> >>> Extensions can be installed into pg_catalog, but they can't get
> >>> low-numbered OIDs.
> >>
> >> Exactly. (To be clear, I had in mind writing something involving
> >> FirstNormalObjectId, not that you should put literal "16384" in the
> >> code.)
> >
> > Actually, 16384 is already used in two other places in check.c, so ...
>
> Yes, but it's a third copy of the comment ("* The query below hardcodes FirstNormalObjectId as 16384 rather than") across the file.
>
> Also, we can return slightly more information about found objects. For example, operator will look like "operator: ||". At least we can get nspname and oid. And, maybe return type for aggregator and leftarg\rightarg types for operator?
But what I wrote already shows what you want.
In database: postgres
aggregate: public.array_accum(anyelement)
operator: public.!@#(anyarray,anyelement)
In my testing, this works great - it shows what you need to put in your DROP
command. If you try it and still wanted the OID, I'll add it for consistency
with check_for_user_defined_{encoding_conversions,postfix_ops}
> BTW comment /* Before v11, used proisagg=true, and afterwards uses prokind='a' */ seems interesting, but irrelevant. We join with pg_aggregate anyway.
Yes, that's why the query doesn't need to include that.
Something is broken in my old clusters and I can't test all the upgrades right
now, but this is my latest.
Attachments:
[text/x-diff] 0001-WIP-pg_upgrade-check-detect-old-polymorphics-from-pr.patch (0B, ../20220624202824.GF22452@telsasoft.com/2-0001-WIP-pg_upgrade-check-detect-old-polymorphics-from-pr.patch)
download
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: pgsql-bugs@postgresql.org
Cc: pryzby@telsasoft.com, x4mmm@yandex-team.ru, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, david.g.johnston@gmail.com, pve@paymorrow.com, pgsql-hackers@lists.postgresql.org
Subject: Re: pg_upgrade (12->14) fails on aggregate
In-Reply-To: <20220624202824.GF22452@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox