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 по дате отправления: