Re: Issue with pg_stat_subscription_stats

On Sat, Mar 12, 2022 at 2:14 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:
>
> So, I noticed that pg_stat_reset_subscription_stats() wasn't working
> properly, and, upon further investigation, I'm not sure the view
> pg_stat_subscription_stats is being properly populated.
>

I have tried the below scenario based on this:
Step:1 Create some data that generates conflicts and lead to apply
failures and then check in the view:

postgres=# select * from pg_stat_subscription_stats;
 subid | subname | apply_error_count | sync_error_count | stats_reset
-------+---------+-------------------+------------------+-------------
 16389 | sub1    |                 4 |                0 |
(1 row)

Step-2: Reset the view
postgres=# select * from pg_stat_reset_subscription_stats(16389);
 pg_stat_reset_subscription_stats
----------------------------------

(1 row)

Step-3: Again, check the view:
postgres=# select * from pg_stat_subscription_stats;
 subid | subname | apply_error_count | sync_error_count |           stats_reset
-------+---------+-------------------+------------------+----------------------------------
 16389 | sub1    |                 0 |                0 | 2022-03-12
08:21:39.156971+05:30
(1 row)

The stats_reset time seems to be populated. Similarly, I have tried by
passing NULL to pg_stat_reset_subscription_stats and it works. I think
I am missing something here, can you please explain the exact
scenario/steps where you observed that this API is not working.


-- 
With Regards,
Amit Kapila.