On 8/9/2005 12:21 PM, Tom Lane wrote:
Csaba Nagy <nagy@xxxxxxxxxxxxxx> writes:
I've executed a "select pg_stat_reset();" as superuser, and all went
away except the offending row...
That only resets the I/O counts (and only for one database), not the
backend activity info.
This reminds me I've forgot to ask, is there any other way of getting
rid of those ghost entries than via big load ?
Not at the moment. It might be worth teaching the pgstats code to
cross-check the activity list every so often, but the only place
where it'd really fit naturally is vacuum_tabstats which is probably
not executed often enough to be helpful.
Or maybe we could just filter the data on the reading side: ignore
anything the stats collector reports that doesn't correspond to a
live backend according to the PGPROC array.
Jan, any thoughts?
The reset call is supposed to throw away everything. If it leaves crap
behind, I'd call that a bug.
IIRC the pg_stat functions don't examine the shared memory, but rely
entirely on information from the stats file. It sure would be possible
to add something there that checks the PGPROC array.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@xxxxxxxxx #
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
