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.