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
"nobuyuki yoshida" writes:
> Hi. I found a bug:I can drop a table with not owner user.
> Document says "Only its owner can drop a table.", but a fuct is not so.
The documentation also says that the owner of a schema can drop anything
in that schema.
regards, tom lane
--
The following bug has been logged online:
Bug reference: 5788
Logged by: nobuyuki yoshida
Email address: nob-yosh...@fissc.co.jp
PostgreSQL version: 8.4.5
Operating system: centos 5.5
Description:I can drop table , with other user's table
Details:
Hi. I found a bug:
