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?
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 |