Re: pg_upgrade (12->14) fails on aggregate
x4mmm@yandex-team.ru
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Robert Haas <robertmhaas@gmail.com>,
"David G. Johnston" <david.g.johnston@gmail.com>,
Petr Vejsada <pve@paymorrow.com>,
pgsql-hackers@lists.postgresql.org
Date: 2022-06-24T18:43:18Z
Lists: pgsql-bugs, pgsql-hackers
> 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?
BTW comment /* Before v11, used proisagg=true, and afterwards uses prokind='a' */ seems interesting, but irrelevant. We join with pg_aggregate anyway.
Thanks!
Best regards, Andrey Borodin.
Commits
-
Tighten pg_upgrade's new check for non-upgradable anyarray usages.
- c7e21e966464 15.0 landed
- 08385ed26196 16.0 landed
- 9783413cbff9 14.5 landed
-
Fix pg_upgrade to detect non-upgradable anyarray usages.
- c069f427855a 15.0 landed
- 175e60a5e35e 14.5 landed
- 09878cdd489f 16.0 landed
-
Remove pg_upgrade support for upgrading from pre-9.2 servers.
- e469f0aaf3c5 15.0 cited