"Benjamin Krajmalnik" <kraj@xxxxxxxxxxxxx> writes: > About a month ago, I started receiving quite a few pgstat timeouts on my > production database. > PostgreSQL 9.0.3 on amd64-portbld-freebsd8.1, compiled by GCC cc (GCC) > 4.2.1 20070719 [FreeBSD], 64-bit > I am not sure where to start looking for the cause. Yeah, so are the rest of us :-(. People have been reporting sometimes seeing these messages without any clear cause. We've been unable to find any bug in Postgres that would explain them, and the obvious explanation of "your system is so overloaded that the stats collector is too slow to respond" isn't very satisfying if response time seems snappy otherwise. I think we have seen one case where the problem was provably caused by significant (multi-second) clock skew between different processors, but that's likely not applicable to many people. Can you reconstruct what changed in your system around the time you started seeing these? > It appears that these timeouts are affecting the performance of the > application - sometimes it hangs for a few seconds before data gets > returned, which was not the case before this. Usually these timeouts are reported by autovacuum, and so should not be affecting the performance of foreground queries, at least not queries that are not explicitly requesting pgstats data. The fact that your log messages don't include any query context reinforces the idea that they are coming from autovacuum for you too. So if you are seeing query response time problems, maybe the pgstat timeouts are another symptom, not the cause, of an underlying too-much-load problem. You might try turning on query duration logging and see if you can correlate response-time glitches and pgstat timeouts to anything else observable, such as peaks of system load average. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
