Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I concur. Let's put the left join(s) into those views and call it
>> good.
> I'd suggest we also add some notes to the documentation that the correct
> approach to dropping users is to disallow access first, then kill any
> existi
On Thu, Apr 7, 2016 at 11:22:08PM +0300, Oskari Saarenmaa wrote:
> 24.03.2016, 18:03, Tom Lane kirjoitti:
> >Robert Haas writes:
> >>I am not really in favor of half-fixing this. If we can't
> >>conveniently wait until a dropped role is completely out of the
> >>system, then I don't see a lot of
Oskari Saarenmaa writes:
> 24.03.2016, 18:03, Tom Lane kirjoitti:
>> I concur. Let's put the left join(s) into those views and call it
>> good.
> Added my patch to the 2016-09 commitfest
> (https://commitfest.postgresql.org/10/601/) as a bug fix as I thought
> not showing all backends in pg_st
24.03.2016, 18:03, Tom Lane kirjoitti:
Robert Haas writes:
I am not really in favor of half-fixing this. If we can't
conveniently wait until a dropped role is completely out of the
system, then I don't see a lot of point in trying to do it in the
limited cases where we can. If LEFT JOIN is th
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > I am not really in favor of half-fixing this. If we can't
> > conveniently wait until a dropped role is completely out of the
> > system, then I don't see a lot of point in trying to do it in the
> > limited cases where we can. If
Robert Haas writes:
> I am not really in favor of half-fixing this. If we can't
> conveniently wait until a dropped role is completely out of the
> system, then I don't see a lot of point in trying to do it in the
> limited cases where we can. If LEFT JOIN is the way to go, then,
> blech, but, s
On Tue, Mar 22, 2016 at 11:35 PM, Kyotaro HORIGUCHI
wrote:
> Even if blocking DROPs is not perfect for all cases,
> unconditionally allowing to DROP a role still doesn't seem proper
> behavior, especially for replication roles. And session logins
> seem to me to have enough reason to be treated di
Hi,
At Tue, 22 Mar 2016 22:47:16 -0500, Jim Nasby wrote
in <56f211c4.6010...@bluetreble.com>
> On 3/22/16 10:35 PM, Kyotaro HORIGUCHI wrote:
> >> Even if we maintained some interlock for a backend's login role
> >> identity,
> >> >I hardly think it would be practical to e.g. lock during transien
On 3/22/16 10:35 PM, Kyotaro HORIGUCHI wrote:
Even if we maintained some interlock for a backend's login role identity,
>I hardly think it would be practical to e.g. lock during transient SET
>ROLE or security-definer-function-call operations. So it's not like we
>can let the permissions system
I had the same problem and thought similar thing.
At Wed, 16 Mar 2016 11:48:10 -0400, Tom Lane wrote in
<16068.1458143...@sss.pgh.pa.us>
> Robert Haas writes:
> > Gee, I would have expected the DROP to be blocked until the user
> > disconnected, like we do for DROP DATABASE.
FWTW, I agree with
Robert Haas writes:
> Gee, I would have expected the DROP to be blocked until the user
> disconnected, like we do for DROP DATABASE.
Making that race-condition-free would require some notion of a lock on
roles, I think. Seems pretty messy compared to the amount of actual
value obtained. There a
On Tue, Mar 15, 2016 at 5:21 PM, Oskari Saarenmaa wrote:
> I was looking into some issues we recently had when dropping db users and
> was surprised to see that dropped users' sessions and transactions
continue
> to work after the role is dropped.
>
> Since dropping a role requires dropping all gr
16.03.2016, 17:48, Tom Lane kirjoitti:
Robert Haas writes:
Gee, I would have expected the DROP to be blocked until the user
disconnected, like we do for DROP DATABASE.
Making that race-condition-free would require some notion of a lock on
roles, I think. Seems pretty messy compared to the am
I was looking into some issues we recently had when dropping db users
and was surprised to see that dropped users' sessions and transactions
continue to work after the role is dropped.
Since dropping a role requires dropping all grants it has (using DROP
OWNED BY ...) the dropped role can't st
14 matches
Mail list logo
