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
|
Список | 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 по дате отправления: