From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Oskari Saarenmaa <os(at)ohmu(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Show dropped users' backends in pg_stat_activity |
Date: | 2016-03-24 15:54:44 |
Message-ID: | CA+TgmoYeN+MDgGPXYJPYoBqttsTWkPw7TEAMtTz5nmiawmD6zA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 22, 2016 at 11:35 PM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> 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 differently than
> disguising as another role using SET ROLE or sec-definer.
>
> The attached patch blocks DROP ROLE for roles that own active
> sessions, and on the other hand prevents a session from being
> activated if the login role is concurrently dropped.
>
> Oskari's LEFT-Join patch is still desirable.
>
> Is this still pointless?
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, so be it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Christian Ullrich | 2016-03-24 15:57:33 | Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used |
Previous Message | Tom Lane | 2016-03-24 15:53:58 | Re: Rationalizing code-sharing among src/bin/ directories |