This is an excellent feature, thanks!
But can we please keep the old boolean waiting column?
I see no reason to break backward-compatibility. Or maybe I'm missing something.
I just had to commit this to make our system run locally on 9.6:
commit 2e189f85fa56724bec5c5cab2fcf0d2f3a4ce22a
Author: Joel Jacobson <j...@trustly.com>
Date: Fri Mar 11 08:19:52 2016 +0700
Make Have_Queries_Waiting() work with both <9.6 and >=9.6.
Apparently pg_stat_activity.waiting was removed by this commit:
commit 53be0b1add7064ca5db3cd884302dfc3268d884e
Author: Robert Haas <rh...@postgresql.org>
Date: Thu Mar 10 12:44:09 2016 -0500
Provide much better wait information in pg_stat_activity.
This forces us to do some ugly version checking to know which column to use.
I for one can think it would have been better to keep the old
boolean column,
which is not entirely useless as sometimes you just want to know
if something is
waiting and don't care about the details, then it's convenient to
have a boolean column
instead of having to write "wait_event IS NOT NULL".
Let's hope they will add back our dear waiting column so we can avoid this
ugly hack before upgrading to 9.6.
diff --git a/public/FUNCTIONS/have_queries_waiting.sql
b/public/FUNCTIONS/have_queries_waiting.sql
index d83e7c8..b54caf5 100644
--- a/public/FUNCTIONS/have_queries_waiting.sql
+++ b/public/FUNCTIONS/have_queries_waiting.sql
@@ -3,9 +3,16 @@ SET search_path TO 'public', pg_catalog;
CREATE OR REPLACE FUNCTION have_queries_waiting() RETURNS boolean
SECURITY DEFINER
SET search_path TO public, pg_temp
- LANGUAGE sql
+ LANGUAGE plpgsql
AS $$
- SELECT EXISTS (SELECT 1 FROM pg_stat_activity WHERE waiting)
+DECLARE
+BEGIN
+IF version() ~ '^PostgreSQL 9\.[1-5]' THEN
+ RETURN EXISTS (SELECT 1 FROM pg_stat_activity WHERE waiting);
+ELSE
+ RETURN EXISTS (SELECT 1 FROM pg_stat_activity WHERE wait_event IS
NOT NULL);
+END IF;
+END;
$$;
On Fri, Mar 11, 2016 at 6:17 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> Or ... maybe this is intentional behavior? Now that I think about it,
>> doesn't each backend cache this info the first time its transaction
>> reads the data?
>
> Your view of pg_stat_activity is supposed to hold still within a
> transaction, yes. Otherwise it'd be really painful to do any complicated
> joins. I think there may be a function to explicitly flush the cache,
> if you really need to see intratransaction changes.
>
> regards, tom lane
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Joel Jacobson
Mobile: +46703603801
Trustly.com | Newsroom | LinkedIn | Twitter
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
