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 |
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 |