Re: Query stucked in pg_stat_activity

On 8/9/2005 12:21 PM, Tom Lane wrote:

> Csaba Nagy <nagy(at)ecircle-ag(dot)com> 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(at)Yahoo(dot)com #