> On 24 May 2024, at 16:20, Tom Lane <t...@sss.pgh.pa.us> wrote: > I've tentatively concluded that I shouldn't have modeled > SHARED_DEPENDENCY_INITACL so closely on SHARED_DEPENDENCY_ACL, > in particular the decision that we don't need such an entry if > there's also SHARED_DEPENDENCY_OWNER.
+1, in light of this report I think we need to go back on that. > I can see two routes to a solution: > > 1. Create SHARED_DEPENDENCY_INITACL, if applicable, whether the > role is the object's owner or not. Then, clearing out the > pg_shdepend entry cues us to go delete the pg_init_privs entry. > > 2. Just always search pg_init_privs for relevant entries > when dropping an object. > > I don't especially like #2 on performance grounds, but it has > a lot fewer moving parts than #1. #1 is more elegant, but admittedly also more complicated. An unscientific guess is that a majority of objects dropped won't have init privs, making the extra scan in #2 quite possibly more than academic. #2 could however be backported and solve the issue in existing clusters. > Another point: shdepReassignOwned explicitly does not touch grants > or default ACLs. It feels like the same should be true of > pg_init_privs entries, Agreed, I can't see why pg_init_privs should be treated differently. > Another thing I'm wondering about right now is privileges on global > objects (roles, databases, tablespaces). The fine manual says > "Although an extension script is not prohibited from creating such > objects, if it does so they will not be tracked as part of the > extension". Presumably, that also means that no pg_init_privs > entries are made; but do we do that correctly? I'm away from a tree to check, but that does warrant investigation. If we don't have a test for it already then it might be worth constructing something to catch that. -- Daniel Gustafsson
