From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <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 11:09:46 |
Message-ID: | CB500650-3F3C-45A5-A06C-96621364AF7E@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi everyone!
Sorry for bumping old thread.
> 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 want to check something like
select * from pg_aggregate join pg_proc on (aggtransfn = pg_proc.oid)
where proname in ('array_append', 'array_prepend','array_cat', 'array_position','array_positions', 'array_remove', 'array_replace', 'width_bucket') ;
select * from pg_operator join pg_proc on (oprcode = pg_proc.oid)
where proname in ('array_append', 'array_prepend','array_cat', 'array_position','array_positions', 'array_remove', 'array_replace', 'width_bucket') and pg_operator.oid >= 16384;
if pg_upgrade is executed with --check option.
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-06-24 11:26:54 | Re: Unify DLSUFFIX on Darwin |
Previous Message | Dilip Kumar | 2022-06-24 11:08:13 | Re: making relfilenodes 56 bits |