Re: Issue with pg_stat_subscription_stats - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Issue with pg_stat_subscription_stats
Date
Msg-id 20220706155306.66s3uy2xw4dm4iy7@awork3.anarazel.de
Whole thread Raw
In response to Re: Issue with pg_stat_subscription_stats  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Issue with pg_stat_subscription_stats
List pgsql-hackers
Hi,

On 2022-07-06 11:41:46 +0900, Masahiko Sawada wrote:
> diff --git a/src/test/regress/sql/subscription.sql b/src/test/regress/sql/subscription.sql
> index 74c38ead5d..6a46956f6e 100644
> --- a/src/test/regress/sql/subscription.sql
> +++ b/src/test/regress/sql/subscription.sql
> @@ -30,6 +30,12 @@ CREATE SUBSCRIPTION regress_testsub CONNECTION 'dbname=regress_doesnotexist' PUB
>  COMMENT ON SUBSCRIPTION regress_testsub IS 'test subscription';
>  SELECT obj_description(s.oid, 'pg_subscription') FROM pg_subscription s;
>  
> +-- Check if the subscription stats are created and stats_reset is updated
> +-- by pg_stat_reset_subscription_stats().
> +SELECT subname, stats_reset IS NULL stats_reset_is_null FROM pg_stat_subscription_stats ORDER BY 1;

Why use ORDER BY 1 instead of just getting the stats for the subscription we
want to test? Seems a bit more robust to show only that one, so we don't get
unnecessary changes if the test needs to create another subscription or such.


> +SELECT pg_stat_reset_subscription_stats(oid) FROM pg_subscription;
> +SELECT subname, stats_reset IS NULL stats_reset_is_null FROM pg_stat_subscription_stats ORDER BY 1;
> +

Perhaps worth resetting again and checking that the timestamp is bigger than
the previous timestamp? You can do that with \gset etc.


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: In-placre persistance change of a relation
Next
From: Robert Haas
Date:
Subject: Re: AIX support - alignment issues