Query stucked in pg_stat_activity
This is a discussion on Query stucked in pg_stat_activity within the Pgsql General forums, part of the PostgreSQL category; --> Jan Wieck wrote: > On 8/9/2005 12:21 PM, Tom Lane wrote: > >>> This reminds me I've forgot to ...
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
04-09-2008, 05:23 AM
| ||||
| ||||
 Re: Query stucked in pg_stat_activity 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? ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq      |
Linear Mode
