Re: Issue with pg_stat_subscription_stats
От | Andres Freund |
---|---|
Тема | Re: Issue with pg_stat_subscription_stats |
Дата | |
Msg-id | 20220706155306.66s3uy2xw4dm4iy7@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Issue with pg_stat_subscription_stats (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Issue with pg_stat_subscription_stats
|
Список | 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 по дате отправления: