Re: Show dropped users' backends in pg_stat_activity

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Oskari Saarenmaa <os(at)ohmu(dot)fi>
Cc: "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-16 15:36:06
Message-ID: CA+TgmoabAtxUpdG7XX3fXoVZef=Miy6Q2=_Ng-nGCfvzBgdbkw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 15, 2016 at 5:21 PM, Oskari Saarenmaa <os(at)ohmu(dot)fi> 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 grants it has (using DROP
OWNED
> BY ...) the dropped role can't start new transactions that do a whole lot
> unless there are objects with access granted to PUBLIC, but any running
> transactions remain running and can write to the database. They can also
> hold locks which interfere with other backends without showing up in most
> activity or lock monitoring tools as they won't appear in
pg_stat_activity.
>
> IMO any open sessions for a dropped user should be automatically
terminated
> when the role is dropped, but that would probably be a bigger change so
> attached a proposed patch for using left joins in pg_stat_activity and
> pg_stat_replication to show activity by dropped roles.

Gee, I would have expected the DROP to be blocked until the user
disconnected, like we do for DROP DATABASE.

--
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 Robert Haas 2016-03-16 15:38:57 Re: Typo in monitoring.sgml
Previous Message Tom Lane 2016-03-16 15:32:49 Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check