Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id EFFB764FCDA for ; Wed, 27 Aug 2008 13:46:20 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 84817-05-3 for ; Wed, 27 Aug 2008 13:46:13 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by postgresql.org (Postfix) with ESMTP id AF0FB6502D3 for ; Wed, 27 Aug 2008 13:45:57 -0300 (ADT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4FAGwhtUjLevdH/2dsb2JhbAAsgTm4CIFo X-IronPort-AV: E=Sophos;i="4.32,279,1217773800"; d="scan'208";a="181566720" Received: from ppp247-71.static.internode.on.net (HELO DevBox.local) ([203.122.247.71]) by ipmail01.adl6.internode.on.net with ESMTP; 28 Aug 2008 02:15:54 +0930 Message-ID: <48B584C0.6080204@Sheeky.Biz> Date: Thu, 28 Aug 2008 02:15:52 +0930 From: Shane Ambler User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Bill Moran CC: henk de wit , "pgsql-performance@postgresql.org" Subject: Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception References: <20080827090123.c0e8e638.wmoran@collaborativefusion.com> In-Reply-To: <20080827090123.c0e8e638.wmoran@collaborativefusion.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200808/352 X-Sequence-Number: 31233 Bill Moran wrote: > On a side note, what version of PG are you using? If it was in a > previous email, I missed it. > He mentioned 8.3.1 in the first email. Although nothing stands out in the 8.3.2 or 8.3.3 fix list (without knowing his table structure or any contrib modules used) I wonder if one of them may resolve his issue. I also wonder if the error is actually sent back from postgresql or whether jdbc is throwing the exception because of a timeout waiting for a response. I would think that with the table in use having 22GB data and 13GB indexes that the long running query has a chance of creating a delay on the connections that is long enough to give jdbc the impression that it isn't responding - generating a misleading error code of "An I/O error" (meaning we know the server got the request but the response from the server isn't coming back) Can you increase the timeout settings on the insert connections that are failing? -- Shane Ambler pgSQL (at) Sheeky (dot) Biz Get Sheeky @ http://Sheeky.Biz