Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 2A43664FD10 for ; Thu, 28 Aug 2008 15:33:31 -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 36308-03 for ; Thu, 28 Aug 2008 15:33:26 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by postgresql.org (Postfix) with ESMTP id C723164FCBD for ; Thu, 28 Aug 2008 15:33:27 -0300 (ADT) Received: by py-out-1112.google.com with SMTP id d37so371864pye.29 for ; Thu, 28 Aug 2008 11:33:27 -0700 (PDT) Received: by 10.114.145.18 with SMTP id s18mr1792846wad.26.1219946761638; Thu, 28 Aug 2008 11:06:01 -0700 (PDT) Received: from ?192.168.1.10? ( [24.7.36.154]) by mx.google.com with ESMTPS id n9sm1627321wag.17.2008.08.28.11.06.00 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Aug 2008 11:06:01 -0700 (PDT) Subject: Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception From: Jeff Davis To: david@lang.hm Cc: Tom Lane , Andrew Sullivan , pgsql-performance@postgresql.org In-Reply-To: References: <82bpze3ou8.fsf@mid.bfk.de> <20080827221338.GP18946@commandprompt.com> <659.1219899383@sss.pgh.pa.us> Content-Type: text/plain Date: Thu, 28 Aug 2008 11:07:18 -0700 Message-Id: <1219946838.22237.26.camel@jdavis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit 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/382 X-Sequence-Number: 31263 On Wed, 2008-08-27 at 23:23 -0700, david@lang.hm wrote: > there are periodic flamefests on the kernel mailing list over the OOM > killer, if you can propose a better algorithm for it to use than the > current one that doesn't end up being just as bad for some other workload > the kernel policy can be changed. > Tried that: http://lkml.org/lkml/2007/2/9/275 All they have to do is *not* count shared memory against the process (or at least not count it against the parent of the process), and the system may approximate sanity. > IIRC the reason why it targets the parent process is to deal with a > fork-bomb type of failure where a program doesn't use much memory itself, > but forks off memory hogs as quickly as it can. if the OOM killer only > kills the children the problem never gets solved. But killing a process won't free shared memory. And there is already a system-wide limit on shared memory. So what's the point of such a bad design? Regards, Jeff Davis