Received: from maia.hub.org (maia-2.hub.org [200.46.204.251])
	by mail.postgresql.org (Postfix) with ESMTP id 6023E1337B34
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Tue, 16 Nov 2010 21:22:26 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia,
	port 10024) with ESMTP id 36984-03
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Wed, 17 Nov 2010 01:22:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id 192711335B36
	for <pgsql-performance@postgresql.org>;
	Tue, 16 Nov 2010 21:22:18 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id oAH1M8jm011498;
	Tue, 16 Nov 2010 20:22:08 -0500 (EST)
To: Josh Berkus <josh@agliodbs.com>
cc: pgsql-performance@postgresql.org, Greg Smith <greg@2ndquadrant.com>
Subject: Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1? 
In-reply-to: <4CE32D36.5040902@agliodbs.com> 
References: <AANLkTi=n3zxiLNFhbpiN=JPQPwB=BhXf9iepw1KOEs8U@mail.gmail.com>
	<4CCDCAA3.4050805@2ndquadrant.com>
	<201011010010.28724.andres@anarazel.de>
	<4CD472CC.80006@2ndquadrant.com>
	<AANLkTinEAmKDz7x356bgX=-6x7zpjK3bB0hYAmKvYHB9@mail.gmail.com>
	<4CE2EBF8.4040602@2ndquadrant.com>
	<4CE312D9.6030503@agliodbs.com> <9058.1289950294@sss.pgh.pa.us>
	<4CE32D36.5040902@agliodbs.com>
Comments: In-reply-to Josh Berkus <josh@agliodbs.com>
	message dated "Tue, 16 Nov 2010 17:17:42 -0800"
Date: Tue, 16 Nov 2010 20:22:08 -0500
Message-ID: <11497.1289956928@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201011/280
X-Sequence-Number: 41304

Josh Berkus <josh@agliodbs.com> writes:
>> Well, we're not going to increase the default to gigabytes, but we could
>> very probably increase it by a factor of 10 or so without anyone
>> squawking.  It's been awhile since I heard of anyone trying to run PG in
>> 4MB shmmax.  How much would a change of that size help?

> Last I checked, though, this comes out of the allocation available to
> shared_buffers.  And there definitely are several OSes (several linuxes,
> OSX) still limited to 32MB by default.

Sure, but the current default is a measly 64kB.  We could increase that
10x for a relatively small percentage hit in the size of shared_buffers,
if you suppose that there's 32MB available.  The current default is set
to still work if you've got only a couple of MB in SHMMAX.

What we'd want is for initdb to adjust the setting as part of its
probing to see what SHMMAX is set to.

			regards, tom lane