Re: Issue with pg_stat_subscription_stats

From: Andres Freund <andres(at)anarazel(dot)de>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Issue with pg_stat_subscription_stats
Date: 2022-07-06 15:53:06
Message-ID: 20220706155306.66s3uy2xw4dm4iy7@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-07-06 15:55:57 Re: AIX support - alignment issues
Previous Message Jacob Champion 2022-07-06 15:44:18 Re: In-placre persistance change of a relation