From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Bernd Helmle <mailings(at)oopsware(dot)de>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Subject: | Re: "pgstat wait timeout" warnings |
Date: | 2011-08-11 14:39:19 |
Message-ID: | CA+TgmoZW-BAoL4J=UepBhR8gzpuB-qKm787PkeRYroxp8kuikg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 11, 2011 at 10:30 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>>> --On 10. August 2011 21:54:06 +0300 Heikki Linnakangas
>>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>>> 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.
>
>> Yes, I have seen it several times as well. I can actually reproduce it
>> without much problems, so if you have some idea to test...
>
> It doesn't surprise me that it's possible to reproduce it under extreme
> I/O load. What I am wondering about is whether there's some bug/effect
> that allows it to happen without that.
I got it several times during a pgbench -i -s 5000 run this morning.
I guess that's a lot of I/O, but I'm not sure I'd refer to one process
filling a table with data as "extreme".
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-08-11 14:46:26 | Re: sha1, sha2 functions into core? |
Previous Message | Tom Lane | 2011-08-11 14:30:11 | Re: "pgstat wait timeout" warnings |