Fix pg_stat_reset_single_table_counters function

Поиск
Список
Период
Сортировка
От Masahiro Ikeda
Тема Fix pg_stat_reset_single_table_counters function
Дата
Msg-id 7cc69f863d9b1bc677544e3accd0e4b4@oss.nttdata.com
обсуждение исходный текст
Ответы Re: Fix pg_stat_reset_single_table_counters function  (Masahiro Ikeda <ikedamsh@oss.nttdata.com>)
Список 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
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Smith
Дата:
Сообщение: Re: Simplify some logical replication worker type checking
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Incorrect handling of OOM in WAL replay leading to data loss