Обсуждение: 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

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_time
>
> Hmm. =A0I 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.

--=20
=A0Magnus Hagander
=A0Me: http://www.hagander.net/
=A0Work: 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