Hi,
Starting with the below commit, pg_stat_reset_single_function_counters,
pg_stat_reset_single_table_counters don't just reset the stats for the
individual function, but also set pg_stat_database.stats_reset.
commit 4c468b37a281941afd3bf61c782b20def8c17047
Author: Magnus Hagander <magnus@hagander.net>
Date: 2011-02-10 15:09:35 +0100
Track last time for statistics reset on databases and bgwriter
Tracks one counter for each database, which is reset whenever
the statistics for any individual object inside the database is
reset, and one counter for the background writer.
Tomas Vondra, reviewed by Greg Smith
/*
@@ -4107,6 +4118,8 @@ pgstat_recv_resetsinglecounter(PgStat_MsgResetsinglecounter *msg, int len)
if (!dbentry)
return;
+ /* Set the reset timestamp for the whole database */
+ dbentry->stat_reset_timestamp = GetCurrentTimestamp();
/* Remove object if it exists, ignore it if not */
if (msg->m_resettype == RESET_TABLE)
The relevant thread is [1], with the most-on-point message at [2].
pg_stat_reset_single_*_counters were introduced in [3]
This behaviour can be trivially (and is) implemented for the shared memory
stats patch. But every time I read over that part of the code it feels just
profoundly wrong to me. Way worse than *not* resetting
pg_stat_database.stats_reset.
Anybody that uses the time since the stats reset as part of a calculation of
transactions / sec, reads / sec or such will get completely bogus results
after a call to pg_stat_reset_single_table_counters().
Maybe I just don't understand what these reset functions are intended for?
Their introduction [3] didn't explain much either. To me the behaviour of
resetting pg_stat_database.stats_reset but nothing else in pg_stat_database
makes them kind of dangerous.
Greetings,
Andres Freund
[1] https://postgr.es/m/7177d0cd40b82409024e7c495e9d6992.squirrel%40sq.gransy.com
[2] https://www.postgresql.org/message-id/4D0E5A54.3060302%40fuzzy.cz
[3] https://www.postgresql.org/message-id/9837222c1001240837r5c103519lc6a74c37be5f1831%40mail.gmail.com
