Horton

Re: pg_upgrade (12->14) fails on aggregate

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: 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-22T23:58:45Z
Lists: pgsql-bugs, pgsql-hackers

Attachments

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 ...
done like that for consistency.
Also fixes parenthesis, typos, and renames vars.

Commits

  1. Tighten pg_upgrade's new check for non-upgradable anyarray usages.

  2. Fix pg_upgrade to detect non-upgradable anyarray usages.

  3. Remove pg_upgrade support for upgrading from pre-9.2 servers.