From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
Cc: | Postgres general mailing list <pgsql-general(at)postgresql(dot)org>, Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Subject: | Re: Query stucked in pg_stat_activity |
Date: | 2005-08-09 16:21:51 |
Message-ID: | 16868.1123604511@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2005-08-09 16:37:49 | Re: Query stucked in pg_stat_activity |
Previous Message | Alvaro Herrera | 2005-08-09 16:11:08 | Re: Solicitud de informacion de psql con php |