Re: Show dropped users' backends in pg_stat_activity - Mailing list pgsql-hackers

From Oskari Saarenmaa
Subject Re: Show dropped users' backends in pg_stat_activity
Date
Msg-id 5706C170.8000202@aiven.io
Whole thread Raw
In response to Re: Show dropped users' backends in pg_stat_activity  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Show dropped users' backends in pg_stat_activity  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Show dropped users' backends in pg_stat_activity  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
24.03.2016, 18:03, Tom Lane kirjoitti:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 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.
>
> I concur.  Let's put the left join(s) into those views and call it
> good.
>
> BTW, I think we would need the left joins even if we had interlocking
> in DROP, just to protect ourselves against race conditions.  Remember
> that what pg_stat_activity shows is a snapshot, which might be more or
> less out of date compared to the catalog contents.

Added my patch to the 2016-09 commitfest 
(https://commitfest.postgresql.org/10/601/) as a bug fix as I thought 
not showing all backends in pg_stat_activity is a bug.  Any chance to 
get it in 9.6?

-- 
Oskari Saarenmaa
Aiven: managed cloud databases
https://aiven.io



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: IF (NOT) EXISTS in psql-completion
Next
From: Victor Pontis
Date:
Subject: Re: [GENERAL] pg_restore casts check constraints differently