Re: Show dropped users' backends in pg_stat_activity

From: Oskari Saarenmaa <os(at)ohmu(dot)fi>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
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-17 07:38:41
Message-ID: 56EA5F01.7040407@ohmu.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

16.03.2016, 17:48, Tom Lane kirjoitti:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Gee, I would have expected the DROP to be blocked until the user
>> disconnected, like we do for DROP DATABASE.
>
> Making that race-condition-free would require some notion of a lock on
> roles, I think. Seems pretty messy compared to the amount of actual
> value obtained. There are good reasons why you can't have a backend
> running in a nonexistent database; but a backend with a nonexistent
> user OID is not really going to be a problem for anything except
> monitoring queries that fail to use left joins where appropriate.

I don't think most people expect dropped users to be able to keep using
the database. If it's not feasible to block DROP ROLE until the user
has disconnected or to kill dropped users' sessions immediately after
they're dropped we should at least show their sessions in
pg_stat_activity and add a note about it in DROP ROLE docs.

/ Oskari

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2016-03-17 07:51:32 Re: [WIP] speeding up GIN build with parallel workers
Previous Message Amit Kapila 2016-03-17 07:19:18 Re: Pushdown target list below gather node (WAS Re: WIP: Upper planner pathification)