From: | Dimos Stamatakis <dimos(dot)stamatakis(at)servicenow(dot)com> |
---|---|
To: | Christoph Moench-Tegeder <cmt(at)burggraben(dot)net> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_upgrade from PG-14.5 to PG-15.1 failing due to non-existing function |
Date: | 2023-01-26 13:10:36 |
Message-ID: | SJ0PR08MB7719278BB073FA19BEE4B296E2CF9@SJ0PR08MB7719.namprd08.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
## Dimos Stamatakis (dimos(dot)stamatakis(at)servicenow(dot)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)
From | Date | Subject | |
---|---|---|---|
Next Message | Jakub Wartak | 2023-01-26 13:40:56 | Re: Syncrep and improving latency due to WAL throttling |
Previous Message | Nikita Malakhov | 2023-01-26 13:08:11 | Re: Inconsistency in vacuum behavior |