Re: BUG #17062: Assert failed in RemoveRoleFromObjectPolicy() on DROP OWNED policy applied to duplicate role
От | Tom Lane |
---|---|
Тема | Re: BUG #17062: Assert failed in RemoveRoleFromObjectPolicy() on DROP OWNED policy applied to duplicate role |
Дата | |
Msg-id | 1067500.1623965562@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17062: Assert failed in RemoveRoleFromObjectPolicy() on DROP OWNED policy applied to duplicate role (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #17062: Assert failed in RemoveRoleFromObjectPolicy() on DROP OWNED policy applied to duplicate role
|
Список | 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
В списке pgsql-bugs по дате отправления: