Re: BUG #17062: Assert failed in RemoveRoleFromObjectPolicy() on DROP OWNED policy applied to duplicate role
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Stephen Frost <sfrost@snowman.net>, Alvaro Herrera <alvherre@alvh.no-ip.org>, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2021-06-22T03:34:52Z
Lists: pgsql-bugs
On Sun, Jun 20, 2021 at 04:15:08PM -0400, Tom Lane wrote:
> Here's a draft patch that gets rid of all the seems-to-me-unnecessary
> stuff in RemoveRoleFromObjectPolicy(). As I said before, the permission
> check seems misguided, the rebuild of non-shared dependencies is a waste
> of cycles, and the table locking is neither necessary nor well designed.
> In this version, if somebody manages to commit a concurrent table drop,
> policy change, etc, you just get a "tuple concurrently deleted" or
> equivalent failure. That's much like most other DDL-conflict cases.
Hm. This version still removes all the shared dependencies and
rebuilds them from scratch for each role. Is that something you
intended to change?
> (I did not look to see if there's any documentation mentioning the
> existing permission check. If there's not, I don't think we need any
> doc changes, since this seems to me to be strictly less surprising
> than the old behavior.)
Don't see any.
> There remains the question of whether we could preserve the policy
> in the edge case of deleting the last role by letting its polroles go
> to empty. But that's clearly not going to be a back-patchable change,
> and I'm not terribly interested in working on it personally.
What would be the advantage of keeping the policy around anyway? The
code behaves like that since its introduction. If you decide to
change that, note that the current code would fail to empty
pg_policy.polroles as the array gets manipulated only when num_roles >
0. So this could leave around policies with roles part of it even
after some DROP OWNED query.
- if (!allowSystemTableMods && IsSystemRelation(rel))
- ereport(ERROR,
- (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- errmsg("permission denied: \"%s\" is a system catalog",
- RelationGetRelationName(rel))));
-
- if (!allowSystemTableMods && IsSystemRelation(rel))
- ereport(ERROR,
- (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- errmsg("permission denied: \"%s\" is a system
- catalog",
- RelationGetRelationName(rel))));
Right. This looks like a copy-paste coming from
RangeVarCallbackForPolicy() and this removes the need to lock the
relation of a policy.
--
Michael
Commits
-
Remove unnecessary failure cases in RemoveRoleFromObjectPolicy().
- fea89d64e8e4 11.13 landed
- f851696a21b2 12.8 landed
- f5b780c45ca6 10.18 landed
- ba815f00a0ce 13.4 landed
- 9c7a150aec71 9.6.23 landed
- 5a0f1c8c0193 14.0 landed
-
Fix misbehavior of DROP OWNED BY with duplicate polroles entries.
- ea5ae3ae1ab0 11.13 landed
- d21fca084356 14.0 landed
- c58a41605ffa 12.8 landed
- b7e3a440775b 10.18 landed
- 33af10c598e2 13.4 landed
- 0b29b41e5b96 9.6.23 landed