Fix pg_stat_reset_single_table_counters function

From: Masahiro Ikeda <ikedamsh(at)oss(dot)nttdata(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: mitsuru(dot)hinata(dot)5432(at)gmail(dot)com
Subject: Fix pg_stat_reset_single_table_counters function
Date: 2023-08-01 06:23:54
Message-ID: 7cc69f863d9b1bc677544e3accd0e4b4@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
v1-0001-Fix-pg_stat_reset_single_table_counters-function.patch text/x-diff 5.7 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2023-08-01 06:28:54 Re: Incorrect handling of OOM in WAL replay leading to data loss
Previous Message Peter Smith 2023-08-01 05:32:10 Re: Simplify some logical replication worker type checking