Re: pg_upgrade fails with non-standard ACL

On Wed, Nov 27, 2019 at 11:35:14AM +0900, Artur Zakirov wrote:
> I've started to implement new backend function similar to
> pg_describe_object() and tried to make new version of the patch. But I'm
> wondering now if it is possible to backpatch new functions to older
> Postgres releases? pg_upgrade will require a presence of this function on an
> older source cluster.

New functions cannot be backpatched because it would require a catalog
bump.

> Other approach is similar to Anastasia's patch, which is scanning pg_proc,
> pg_class, pg_attribute and others to get modified ACL's and compare it with
> initial ACL from pg_init_privs. Next step is to find objects which names or
> signatures were changed using pg_describe_object() and scanning pg_depend of
> new cluster

Yeah, the actual take is if we want to make the frontend code more
complicated with a large set of SQL queries to check that each object
ACL is modified, which adds an additional maintenance cost in
pg_upgrade. Or if we want to keep the frontend simple and have more
backend facility to ease cross-catalog lookups for ACLs. Perhaps we
could also live with just checking after the ACLs of functions in the
short term and perhaps it covers most of the cases users would care
about.. That's tricky to conclude about and I am not sure which path
is better in the long-term, but at least it's worth discussing all
possible candidates IMO so as we make sure to not miss anything.

> (there is a problem here though: there are no entries for
> relations columns).

When it comes to column ACLs, pg_shdepend stores a dependency between
the column's relation and the role.
--
Michael