not all pg_stat_database fields reset after pg_stat_reset()
After calling pg_stat_reset, some of the database stats fields are not
actually reset, the value is preserved. I've found the bug is actually in
pgstat_recv_resetcounter function, where only some of the
PgStat_StatDBEntry fields are reset to 0.
This is true for those 6 fields:
n_tuples_returned
n_tuples_fetched
n_tuples_inserted
n_tuples_updated
n_tuples_deleted
last_autovac_time
The docs for "pg_stat_reset()" say "Reset all statistics counters for the
current database to zero (requiret superuser privileges)" and I don't see
any reason why these fields should not be reset, so I guess it's a bug.
See the patch attached (against current dev version).
regards
Tomas
Attachments:
missing-fields.difftext/plain; name=missing-fields.diffDownload+8-0
tv@fuzzy.cz writes:
After calling pg_stat_reset, some of the database stats fields are not
actually reset, the value is preserved. I've found the bug is actually in
pgstat_recv_resetcounter function, where only some of the
PgStat_StatDBEntry fields are reset to 0.
This is true for those 6 fields:
n_tuples_returned
n_tuples_fetched
n_tuples_inserted
n_tuples_updated
n_tuples_deleted
last_autovac_time
Hmm. I think that not resetting the n_tuples_xxx fields was simply an
oversight in Magnus' patch that added them,
http://archives.postgresql.org/pgsql-committers/2007-03/msg00144.php
Magnus, was this intentional by any chance?
However, I disagree with resetting last_autovac_time ... that's not a
counter, so there's no particularly good reason to discard its value.
regards, tom lane
However, I disagree with resetting last_autovac_time ... that's not a
counter, so there's no particularly good reason to discard its value.
Oh yeah, I see. Haven't realized that when writing the patch.
regards
Tomas
tv@fuzzy.cz writes:
However, I disagree with resetting last_autovac_time ... that's not a
counter, so there's no particularly good reason to discard its value.
Oh yeah, I see. Haven't realized that when writing the patch.
... on the other hand, the reset operation is discarding the per-table
last-vacuum times, so maybe discarding the database-level value too is
more consistent. Not sure.
regards, tom lane
On Sat, Dec 11, 2010 at 18:31, Tom Lane <tgl@sss.pgh.pa.us> wrote:
tv@fuzzy.cz writes:
After calling pg_stat_reset, some of the database stats fields are not
actually reset, the value is preserved. I've found the bug is actually in
pgstat_recv_resetcounter function, where only some of the
PgStat_StatDBEntry fields are reset to 0.This is true for those 6 fields:
n_tuples_returned
n_tuples_fetched
n_tuples_inserted
n_tuples_updated
n_tuples_deleted
last_autovac_timeHmm. I think that not resetting the n_tuples_xxx fields was simply an
oversight in Magnus' patch that added them,
http://archives.postgresql.org/pgsql-committers/2007-03/msg00144.php
Magnus, was this intentional by any chance?
Nope, not that I can recall. Looks like an oversight.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
On Sat, Dec 11, 2010 at 18:31, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Hmm. �I think that not resetting the n_tuples_xxx fields was simply an
oversight in Magnus' patch that added them,
http://archives.postgresql.org/pgsql-committers/2007-03/msg00144.php
Magnus, was this intentional by any chance?
Nope, not that I can recall. Looks like an oversight.
OK, applied, along with the last_autovac_time reset --- I concluded that
keeping that at the database level wouldn't be consistent, since we're
throwing it away at the table level.
regards, tom lane