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
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) |