Re: WARNING: pgstat wait timeout

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: WARNING: pgstat wait timeout
Дата
Msg-id 9837222c1001290516j461e0e5eu19aa92a7da583f56@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WARNING: pgstat wait timeout  (Greg Smith <greg@2ndquadrant.com>)
Список pgsql-hackers
2010/1/29 Greg Smith <greg@2ndquadrant.com>:
> I just found a few of these errors in a log file during some pgbench testing tonight.  Linux, recent CVS HEAD; given
therange of systems and versions this has been reported against now, this bug doesn't look like a platform or
version/buildspecific issue. 
>
> Unfortunately the instance I had up wasn't setup very well for logging, but I did notice that all of the ones I saw
hadnearby messages about autovacuum issues, which seems to match Tom's earlier suggestion at
http://archives.postgresql.org/pgsql-bugs/2009-07/msg00083.phpthat the source of the warning (but not necessarily the
underlyingproblem) for these is the autovacuum launcher complaining; here's two different sets: 
>
> ERROR:  canceling autovacuum task
> CONTEXT:  automatic analyze of table "pgbench.public.pgbench_accounts"
> WARNING:  pgstat wait timeout
> WARNING:  pgstat wait timeout
> ERROR:  canceling autovacuum task
> CONTEXT:  automatic analyze of table "pgbench.public.pgbench_accounts"
>
> WARNING:  pgstat wait timeout
> ERROR:  canceling autovacuum task
> CONTEXT:  automatic analyze of table "pgbench.public.pgbench_accounts"
> ERROR:  canceling autovacuum task
> CONTEXT:  automatic analyze of table "pgbench.public.pgbench_accounts"
>
> Because of what I'm (not) seeing in pg_stat_bgwriter, I'm suspicious that its underlying work or messages may be
involvedhere.  I'm not seeing the sort of totals I expect in that view after these large bouts of activity.  Now, my
usetonight has included the new pg_stat_reset_shared('bgwriter') to clear out those stats between runs, so perhaps
that'sinvolved too.  Guessing not only because of the reports going back to 8.4 that also have this error message. 
>
> Will keep an eye out for this one now that I know I might run into it, have already cranked up the logging and will
lookfor something reproducible to gather more info. 

I've seen this happen semi-frequently during initdb on win32 on an
Amazon EC2 image. I attributed it to the combination of windows and
overloaded virtualization, but it may just be that it shows up more
often there.

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Pathological regexp match
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: HS/SR and smart shutdown