Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 4A0446502CB for ; Thu, 28 Aug 2008 23:32:35 -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 82619-07 for ; Thu, 28 Aug 2008 23:32:25 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from lists.commandprompt.com (host-159.commandprompt.net [207.173.203.159]) by postgresql.org (Postfix) with ESMTP id 8B17C6502C8 for ; Thu, 28 Aug 2008 23:32:31 -0300 (ADT) Received: from perhan.alvh.no-ip.org (200-126-66-230.bk5-dsl.surnet.cl [200.126.66.230]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m7T2ZQRt006626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Aug 2008 19:35:30 -0700 Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 9275D47CA7; Thu, 28 Aug 2008 22:32:18 -0400 (CLT) Date: Thu, 28 Aug 2008 22:32:18 -0400 From: Alvaro Herrera To: Scott Marlowe Cc: Matthew Dennis , david@lang.hm, Matthew Wakeling , PostgreSQL Performance Subject: Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception Message-ID: <20080829023218.GK8424@alvh.no-ip.org> References: <48B6EA7E.2090707@emolecules.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Thu, 28 Aug 2008 19:35:30 -0700 (PDT) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200808/407 X-Sequence-Number: 31288 Scott Marlowe escribió: > scenario 1: There's a postmaster, it owns all the child processes. > It gets killed. The Postmaster gets restarted. Since there isn't one > running, it comes up. Actually there's an additional step required at this point. There isn't a postmaster running, but a new one refuses to start, because the shmem segment is in use. In order for the second postmaster to start, the sysadmin must remove the PID file by hand. > starts new child processes. Meanwhile, the old child processes that > don't belong to it are busy writing to the data store. Instant > corruption. In this scenario, it is both a kernel fault and sysadmin stupidity. The corruption that ensues is 100% deserved. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support