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

From Bruce Momjian
Subject Re: Show dropped users' backends in pg_stat_activity
Date
Msg-id 20160427161012.GM13058@momjian.us
Whole thread Raw
In response to Re: Show dropped users' backends in pg_stat_activity  (Oskari Saarenmaa <os@aiven.io>)
List pgsql-hackers
On Thu, Apr  7, 2016 at 11:22:08PM +0300, Oskari Saarenmaa wrote:
> 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?

Do we need a comment in the query explaining why a left join is needed,
e.g. "Use LEFT JOIN in case the role has been dropped"?  That wouldn't
be obvious to me.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+                     Ancient Roman grave inscription +



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Suspicious behaviour on applying XLOG_HEAP2_VISIBLE.
Next
From: "Daniel Verite"
Date:
Subject: Re: Rename max_parallel_degree?