Обсуждение: pg_upgrade from PG-14.5 to PG-15.1 failing due to non-existing function
Hi hackers,
I attempted to perform an upgrade from PG-14.5 to PG-15.1 with pg_upgrade and unfortunately it errors out because of a function that does not exist anymore in PG-15.1.
The function is ‘pg_catalog.close_lb’ and it exists in 14.5 but not in 15.1.
In our scenario we changed the permissions of this function in PG14.5 (via an automated tool) and then pg_upgrade tries to change the permissions in PG15.1 as well.
Steps to reproduce:
- Run initdb for 14.5
- Run initdb for 15.1
- Run psql client on 14.5
- postgres=# REVOKE ALL ON FUNCTION close_lb(line, box) FROM $USER;
- Run pg_upgrade from 14.5 to 15.1
This will error out because pg_upgrade will attempt to REVOKE the persmissions on close_lb on 15.1.
Is there a way to specify which functions/objects to exclude in pg_upgrade?
Thanks in advance!
Dimos
(ServiceNow)
Re: pg_upgrade from PG-14.5 to PG-15.1 failing due to non-existing function
## Dimos Stamatakis (dimos.stamatakis@servicenow.com): > In our scenario we changed the permissions of this function in PG14.5 > (via an automated tool) and then pg_upgrade tries to change the > permissions in PG15.1 as well. Given that this function wasn't even documented and did nothing but throw an error "function close_lb not implemented" - couldn't you revert that permissions change for the upgrade? (if it comes to the worst, a superuser could UPDATE pg_catalog.pg_proc and set proacl to NULL for that function, but that's not how you manage ACLs in production, it's for emergency fixing only). Regards, Christoph -- Spare Space
Hi, On 1/25/23 19:38, Dimos Stamatakis wrote: > > Hi hackers, > > I attempted to perform an upgrade from PG-14.5 to PG-15.1 with > pg_upgrade and unfortunately it errors out because of a function that > does not exist anymore in PG-15.1. > > The function is ‘pg_catalog.close_lb’ and it exists in 14.5 but not in > 15.1. > > In our scenario we changed the permissions of this function in PG14.5 > (via an automated tool) and then pg_upgrade tries to change the > permissions in PG15.1 as well. > Here [1] is a very similar issue that has been reported in 2019. The patch didn't make it in but it also seems to not fix the issue reported by Dimos. The patch in [1] seems to be concerned with changed function signatures rather than with dropped functions. Maybe [1] could be revived and extended to also ignore dropped functions? [1] https://www.postgresql.org/message-id/flat/f85991ad-bbd4-ad57-fde4-e12f0661dbf0%40postgrespro.ru -- David Geier (ServiceNow)
Re: pg_upgrade from PG-14.5 to PG-15.1 failing due to non-existing function
## Dimos Stamatakis (dimos.stamatakis@servicenow.com):
> In our scenario we changed the permissions of this function in PG14.5
> (via an automated tool) and then pg_upgrade tries to change the
> permissions in PG15.1 as well.
Given that this function wasn't even documented and did nothing but
throw an error "function close_lb not implemented" - couldn't you
revert that permissions change for the upgrade? (if it comes to the
worst, a superuser could UPDATE pg_catalog.pg_proc and set proacl
to NULL for that function, but that's not how you manage ACLs in
production, it's for emergency fixing only).
Thanks Christoph! Actually, I already tried reverting the permissions but pg_upgrade attempts to replicate the revert SQL statement as well 😊
It would be nice to make pg_upgrade ignore some statements while upgrading.
As David mentions, we can alter the patch to ignore dropped functions.
Thanks,
Dimos
(ServiceNow)