Magnus Hagander writes:
> On Sat, Dec 11, 2010 at 18:31, Tom Lane 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
On Sat, Dec 11, 2010 at 18:31, Tom Lane wrote:
> t...@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_StatD
t...@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-
> 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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make ch
t...@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 thos
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
