Re: Show dropped users' backends in pg_stat_activity

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Show dropped users' backends in pg_stat_activity
Дата
Msg-id CA+TgmoYeN+MDgGPXYJPYoBqttsTWkPw7TEAMtTz5nmiawmD6zA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Show dropped users' backends in pg_stat_activity  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: Show dropped users' backends in pg_stat_activity  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Mar 22, 2016 at 11:35 PM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Rationalizing code-sharing among src/bin/ directories
Следующее
От: Christian Ullrich
Дата:
Сообщение: Re: BUG #13854: SSPI authentication failure: wrong realm name used