Re: Show dropped users' backends in pg_stat_activity

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

In response to

Responses

Browse pgsql-hackers by date

  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