Fix pg_stat_reset_single_table_counters function - Mailing list pgsql-hackers

From Masahiro Ikeda
Subject Fix pg_stat_reset_single_table_counters function
Date
Msg-id 7cc69f863d9b1bc677544e3accd0e4b4@oss.nttdata.com
Whole thread Raw
Responses Re: Fix pg_stat_reset_single_table_counters function
List pgsql-hackers
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?

* reproduce procedure

SELECT COUNT(*) FROM pg_stat_database;
SELECT pg_stat_reset_single_table_counters('pg_database'::regclass);
SELECT seq_scan FROM pg_stat_all_tables WHERE relid = 
'pg_database'::regclass;

* unexpected result
  * Rename OverrideSearchPath to SearchPathMatcher (current HEAD: 
d3a38318a)
  * pgstat: store statistics in shared memory (5891c7a8e)

psql=# SELECT seq_scan FROM pg_stat_all_tables WHERE relid = 
'pg_database'::regclass;
  seq_scan
----------
        11
(1 row)

* expected result
  * Enhance pg_stat_reset_single_table_counters function (e04267844)
  * pgstat: normalize function naming (be902e2651), which is previous 
commit of 5891c7a8e.

psql=# SELECT seq_scan FROM pg_stat_all_tables WHERE relid = 
'pg_database'::regclass;
  seq_scan
----------
         0
(1 row)

Regards,
-- 
Masahiro Ikeda
NTT DATA CORPORATION
Attachment

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Simplify some logical replication worker type checking
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Incorrect handling of OOM in WAL replay leading to data loss