pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org, Magnus Hagander <magnus(at)hagander(dot)net>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Tomas Vondra <tv(at)fuzzy(dot)cz>
Subject: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset
Date: 2022-03-24 00:55:16
Message-ID: 20220324005516.h577s6iadw4kxnwb@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)hagander(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-03-24 00:59:38 Re: pg_stat_reset_single_*_counters vs pg_stat_database.stats_reset
Previous Message Michael Paquier 2022-03-24 00:40:23 Re: Add pg_freespacemap extension sql test