Re: Grantor name gets lost when grantor role dropped - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Grantor name gets lost when grantor role dropped
Date
Msg-id 4090.1178296889@sss.pgh.pa.us
Whole thread Raw
In response to Re: Grantor name gets lost when grantor role dropped  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-bugs
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> Both of these have got race conditions ... not but what the dependency
>> code has got race condition problems already, but maybe we should try
>> to avoid introducing more?  I haven't got any better ideas though.

> I couldn't parse this paragraph very well.  However I'm not sure why you
> say the dependency code has got race conditions?  We do lock the object
> before checking the dependencies, so it's not possible to add a new
> dependency while we're dropping the object.

Sorry, I was thinking of the regular dependency code, which has open
bug report(s) based on exactly the fact that there's no such locking.
shdepend may be OK, since it's fundamentally only dealing in roles.

>> Why is it that we record grantor at all?  One could argue that granting
>> membership in a role is done on behalf of that role and there's no real
>> need to remember exactly who did it.

> I think you should ask Stephen Frost about that -- added to CC.

> If the grantor bit is not important, then what we should do is just omit
> emitting the GRANTED BY part in pg_dumpall, which fixes this report.

It's at least something we should reflect on before sweating hard to
make it work...

            regards, tom lane

pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Grantor name gets lost when grantor role dropped
Next
From: "Jose Blanco"
Date:
Subject: Re: order by question.