On 10.08.2011 21:45, Tom Lane wrote:
We occasionally see $SUBJECT in the buildfarm, and I've also recently
had reports of them from Red Hat customers. The obvious theory is that
these reflect high load preventing the stats collector from responding,
but it would really take pretty crushing load to make that happen if
there were not anything funny going on.
It struck me just now while reviewing the latch code that pg_usleep
could sleep for less than the expected time if a signal happened, and
if that happened repeatedly for some reason, perhaps the loop could
complete in much less than the nominal time. I'm not sure I believe
that idea either, but anyway I'm feeling motivated to try to gather more
data.
I've also seen this on my laptop occasionally. The most recent case I
remember was when I COPYed a lot of data, so that the harddisk was
really busy. The system was a bit unresponsive anyway, because of all
the I/O happening.
So my theory is that if the I/O is really busy, write() on the stats
file blocks for more than 5 seconds, and you get the timeout.
Does anyone have a problem with sticking a lot of debugging printout
into backend_read_statsfile() in HEAD only? I'm envisioning it starting
to dump assorted information including elapsed time, errno values, etc
once the loop counter is more than halfway to expiration, which is
already a situation that we shouldn't see under normal conditions.
No objections here.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
