Re: Query stucked in pg_stat_activity

From: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
To: Jan Wieck <JanWieck(at)Yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Postgres general mailing list <pgsql-general(at)postgresql(dot)org>
Subject: Re: Query stucked in pg_stat_activity
Date: 2005-08-09 17:15:17
Message-ID: 42F8E4A5.3090104@zeut.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Jan Wieck wrote:

> On 8/9/2005 12:21 PM, Tom Lane wrote:
>
>>> 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.

Is that the same stats reset that effects autovacuum?

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2005-08-09 17:18:53 Re: [GENERAL] postgres & server encodings
Previous Message brew 2005-08-09 17:00:44 Re: Poll on your LAPP Preferences