From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Petr Vejsada <pve(at)paymorrow(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_upgrade (12->14) fails on aggregate |
Date: | 2022-06-27 23:30:03 |
Message-ID: | 20220627233003.GE19662@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Sat, Jun 25, 2022 at 03:34:49PM +0500, Andrey Borodin wrote:
> > On 25 Jun 2022, at 01:28, Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
>
> > this is my latest.
> > <0001-WIP-pg_upgrade-check-detect-old-polymorphics-from-pr.patch>
>
> Let's rename "databases_with_old_polymorphics.txt" to somthing like "old_polymorphics.txt" or maybe even "incompatible_polymorphics_usage.txt"?
> I think you will come up with a better name, my point is here everythin is in "databases", and "old" doesn't describe essence of the problem.
> Also, let's check that oid of used functions belong to system catalog (<16384)? We don't care about user-defined functions with the same name.
Right now, we test
=ANY(ARRAY['array_remove(anyarray,anyelement)',...]::regprocedure)
..which will find the system's array_remove, and not some other one, due to
ALWAYS_SECURE_SEARCH_PATH_SQL (which is also why ::regprocedure prints a
namespace for the non-system functions we're interested in displaying).
I had "transnsp.nspname='pg_catalog'", which was redundant, so I removed it.
I tested that this allows upgrades with aggregates on top of non-system
functions of the same name/args:
postgres=# CREATE FUNCTION array_append(anyarray, anyelement) RETURNS ANYARRAY LANGUAGE SQL AS $$ $$;
postgres=# CREATE AGGREGATE foo(anyelement) (sfunc=public.array_append, stype=anyarray, initcond='{}');
> And, probably, we can do this unconditionally:
> if (old_cluster.major_version >= 9500)
> appendPQExpBufferStr(&old_polymorphics,
> Nothing bad will happen if we blacklist usage of nonexistent functions.
Nope, it's as I said: this would break pg_upgrade from older versions.
> I realized that my latest patch would break upgrades from old servers, which do
> not have array_position/s nor width_bucket, so ::reprocedure would fail. Maybe
> Andrey's way is better (checking proname rather than its OID).
This fixes several error with the version test.
--
Justin
Attachment | Content-Type | Size |
---|---|---|
0001-WIP-pg_upgrade-check-detect-old-polymorphics-from-pr.patch | text/x-diff | 6.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2022-06-28 00:37:20 | Re: BUG #17385: "RESET transaction_isolation" inside serializable transaction causes Assert at the transaction end |
Previous Message | David Johansen | 2022-06-27 20:38:21 | Auto-vacuum timing out and preventing connections |
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2022-06-28 00:18:07 | Re: Allowing REINDEX to have an optional name |
Previous Message | Jacob Champion | 2022-06-27 21:40:01 | Re: [PoC] Let libpq reject unexpected authentication requests |