Re: Fix pg_stat_reset_single_table_counters function - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Fix pg_stat_reset_single_table_counters function
Date
Msg-id CAD21AoCnFqzzW7DUW67Art=2w_Z3gwKU1suSn0d0UtUPtdbt_g@mail.gmail.com
Whole thread Raw
In response to Re: Fix pg_stat_reset_single_table_counters function  (Masahiro Ikeda <ikedamsh@oss.nttdata.com>)
Responses Re: Fix pg_stat_reset_single_table_counters function
List pgsql-hackers
On Thu, Aug 10, 2023 at 2:10 PM Masahiro Ikeda <ikedamsh@oss.nttdata.com> wrote:
>
> On 2023-08-01 15:23, Masahiro Ikeda wrote:
> > Hi,
> >
> > My colleague, Mitsuru Hinata (in CC), found the following issue.
> >
> > The documentation of pg_stat_reset_single_table_counters() says
> >> pg_stat_reset_single_table_counters ( oid ) → void
> >> Resets statistics for a single table or index in the current database
> >> or shared across all databases in the cluster to zero.
> >> This function is restricted to superusers by default, but other users
> >> can be granted EXECUTE to run the function.
> > https://www.postgresql.org/docs/devel/monitoring-stats.html
> >
> > But, the stats will not be reset if the table shared across all
> > databases is specified. IIUC, 5891c7a8e seemed to have mistakenly
> > removed the feature implemented in e04267844. What do you think?

Good catch! I've confirmed that the issue has been fixed by your patch.

However, I'm not sure the added regression tests are stable since
autovacuum workers may scan the pg_database and increment the
statistics after resetting the stats. Also, the patch bumps the
CATALOG_VERSION_NO but I don't think it's necessary.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Support to define custom wait events for extensions
Next
From: Christoph Berg
Date:
Subject: Re: A failure in 031_recovery_conflict.pl on Debian/s390x