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>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us> |
Subject: | Re: array_cat anycompatible change is breaking xversion upgrade tests |
Date: | 2022-06-24 13:30:53 |
Message-ID: | 20220624133052.GD22452@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jun 24, 2022 at 04:09:46PM +0500, Andrey Borodin wrote:
> Hi everyone!
>
> Sorry for bumping old thread.
Please find this newer thread+patch here ;)
https://www.postgresql.org/message-id/20220614230949.GX29853@telsasoft.com
> On 25 May 2021, at 21:14, Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> >
> > Such aggregate functions should be dropped before upgrade/restore and then
> > re-created afterwards using the "anycompatible" functions. The affected
> > functions are: array_append, array_prepend, array_cat, array_position,
> > array_positions, array_remove, array_replace, and width_bucket.
>
> We've just stumbled upon the problem in our service. Would it be backpatchable to add this check to pg_upgrade?
I guess you mean to backpatch to v14 for people upgrading from v13.
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).
--
Justin
From | Date | Subject | |
---|---|---|---|
Next Message | Leif Harald Karlsen | 2022-06-24 13:58:43 | Implement hook for self-join simplification |
Previous Message | Jelte Fennema | 2022-06-24 13:23:49 | Re: WIP Patch: Add a function that returns binary JSONB as a bytea |