|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Oskari Saarenmaa <os(at)ohmu(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Show dropped users' backends in pg_stat_activity|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
Even if we maintained some interlock for a backend's login role identity,
I hardly think it would be practical to e.g. lock during transient SET
ROLE or security-definer-function-call operations. So it's not like we
can let the permissions system assume that a role OID being inquired about
always matches a live entry in pg_authid.
regards, tom lane
|Next Message||Pavel Stehule||2016-03-16 15:50:56||Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types|
|Previous Message||Joe Conway||2016-03-16 15:46:15||Re: plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types|