Re: BUG #17062: Assert failed in RemoveRoleFromObjectPolicy() on DROP OWNED policy applied to duplicate role
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Stephen Frost <sfrost@snowman.net>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2021-06-17T21:32:42Z
Lists: pgsql-bugs
I wroteL > PG Bug reporting form <noreply@postgresql.org> writes: >> When executing the following query: >> CREATE USER role1; >> CREATE TABLE t1(id int); >> CREATE POLICY p1 ON t1 TO role1,role1 USING (true); >> DROP OWNED BY role1; >> The server halts with the failed assertion: > Nice. Seems to be that way at least as far back as 9.6, too. So the proximate problem is RemoveRoleFromObjectPolicy's unfounded assumption that there are no duplicate OIDs in a pg_policy.polroles entry. But that function has got some other serious problems too: * Locking. It acquires lock on the policy's relation only after it looks up the pg_policy entry. By that point the entry could be gone or modified. * Why is it expensively reconstructing the dependencies of the policy expressions? Those aren't going to be changed by this operation. AFAICS it ought to be sufficient to remove and rebuild the policy's shared dependencies. I wonder whether other operations on policies share either of these issues. regards, tom lane
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