Stephen Frost writes:
> * Tom Lane ([email protected]) 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 ([email protected]) 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 <[email protected]>
> 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
<[email protected]>
> 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
13 matches
Mail list logo
