Re: BUG #17062: Assert failed in RemoveRoleFromObjectPolicy() on DROP OWNED policy applied to duplicate role

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17062: Assert failed in RemoveRoleFromObjectPolicy() on DROP OWNED policy applied to duplicate role
Date: 2021-06-20 20:15:08
Message-ID: 1573181.1624220108@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

(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.)

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.

regards, tom lane

Attachment Content-Type Size
clean-up-RemoveRoleFromObjectPolicy-1.patch text/x-diff 9.1 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2021-06-20 21:00:01 BUG #17066: Cache lookup failed when null (unknown) is passed as anycompatiblemultirange
Previous Message Bernd Hopp 2021-06-20 17:45:21 Re: 'within group'- or percentile_cont-expression seems to have ramifications on table ordering