Received: from localhost (unknown [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 9DD882E3440; Wed, 12 Dec 2007 12:43:08 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 90542-02; Wed, 12 Dec 2007 12:43:01 -0400 (AST) Received: from main2.mycybernet.net (main2.mycybernet.net [209.222.63.140]) by postgresql.org (Postfix) with ESMTP id D143F2E36BE; Wed, 12 Dec 2007 12:43:01 -0400 (AST) Received: from 227-54-222-209.mycybernet.net ([209.222.54.227] helo=crankycanuck.ca) by main2.mycybernet.net with esmtp (Exim 4.62) (envelope-from ) id 1J2Ufl-0004vj-BU; Wed, 12 Dec 2007 11:43:01 -0500 Received: by crankycanuck.ca (Postfix, from userid 1000) id 67DF150476; Wed, 12 Dec 2007 11:42:56 -0500 (EST) Date: Wed, 12 Dec 2007 11:42:56 -0500 From: Andrew Sullivan To: pgsql-admin@postgresql.org, pgsql-docs@postgresql.org Subject: Re: Dangerous hint in the PostgreSQL manual Message-ID: <20071212164256.GV31954@crankycanuck.ca> Mail-Followup-To: Andrew Sullivan , pgsql-admin@postgresql.org, pgsql-docs@postgresql.org References: <20071210162612.a9y113hzjkookooc@webmail.kwsoft.de> <20071210204750.GA22340@crankycanuck.ca> <20071211092338.3vsx57ymsswsckw0@webmail.kwsoft.de> <20071211134231.GL26741@crankycanuck.ca> <20071211150836.00ql03638kok48s0@webmail.kwsoft.de> <20071211162229.GD27409@crankycanuck.ca> <20071212171924.uir6apjasoog00c4@webmail.kwsoft.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071212171924.uir6apjasoog00c4@webmail.kwsoft.de> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/68 X-Sequence-Number: 27585 Dear docs mavens: Please see below for a possible adjustment to the docs. Is it agreeable? If so, I'll see about putting together a patch. On Wed, Dec 12, 2007 at 05:19:24PM +0100, Listaccount wrote: > >What I _would_ support in the docs is the following addition in 17.4.3, > >where this is discussed: > > > > . . .it will lower the chances significantly and will therefore > > lead to more robust system behavior. It may also cause fork() to fail > > when the machine appears to have available memory. This is done by > > selecting. . . > > > >Or something like that. This would warn potential users that they really > >do > >need to read their kernel docs. > > On this one we can agree. Maybe we should mention the root-cause. > > "It may also cause fork() to fail when the machine appears to have > available memory because of other applications doing careless memory > allocation" > > Would be nice to save others from learning about this the hard way. > > Regards > > Andreas