Re: Query stucked in pg_stat_activity
От | Matthew T. O'Connor |
---|---|
Тема | Re: Query stucked in pg_stat_activity |
Дата | |
Msg-id | 42F8E4A5.3090104@zeut.net обсуждение исходный текст |
Ответ на | Re: Query stucked in pg_stat_activity (Jan Wieck <JanWieck@Yahoo.com>) |
Список | 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?
В списке pgsql-general по дате отправления: