Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 437BE64FD06 for ; Fri, 29 Aug 2008 02:38:30 -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 57134-02 for ; Fri, 29 Aug 2008 02:38:23 -0300 (ADT) X-Greylist: delayed 00:22:14.550898 by SQLgrey-1.7.6 Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.145]) by postgresql.org (Postfix) with ESMTP id D8DC464FCDE for ; Fri, 29 Aug 2008 02:38:24 -0300 (ADT) Received: from [80.229.150.39] (helo=pd600.barnhouse) by ptb-relay01.plus.net with esmtp (Exim) id 1KYwL7-0004MK-3d; Fri, 29 Aug 2008 06:16:05 +0100 Received: from [192.168.0.88] (unknown [192.168.0.88]) by pd600.barnhouse (Postfix) with ESMTP id 8B0974E1C70; Fri, 29 Aug 2008 06:21:28 +0100 (BST) Message-ID: <48B78662.5010208@mansionfamily.plus.com> Date: Fri, 29 Aug 2008 06:17:22 +0100 From: James Mansion Organization: MsgWare User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: david@lang.hm CC: Florian Weimer , 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: <82bpze3ou8.fsf@mid.bfk.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Plusnet-Relay: 9fd2138c16f0a9a76554772c14c8af89 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/416 X-Sequence-Number: 31297 david@lang.hm wrote: > for example if you have a process that uses 1G of ram (say firefox) > and it needs to start a new process (say acroread to handle a pdf > file), what it does is it forks the firefox process (each of which > have 1G of ram allocated), and then does an exec of the acroread > process (releasing the 1G of ram previously held by that copy of the > firefox process) > Indeed, which is why we have vfork. And, OK, vfork is busted if you have a threaded environment, so we have posix_spawn and posix_spawnp. It is also worth noting that the copy isn't really a full copy on any decent modern UNIX - it is a reservation against the total swap space available. Most pages will be happilly shared copy-on-write and never fully copied to the child before the exec. I can't see how an OS can lie to processes about memory being allocated to them and not be ridiculed as a toy, but there you go. I don't think Linux is the only perpetrator - doesn't AIX do this too? The 'bests trategy' for the OOM killer is not to have one, and accept that you need some swap space available (it doesn't have to be fast since it won't actually be touched) to help out when fork/exec happens in big process images. James