Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id BB94A64FE4B
	for <pgsql-general-postgresql.org@postgresql.org>;
	Wed, 15 Oct 2008 00:08:29 -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 06094-06 for
	<pgsql-general-postgresql.org@postgresql.org>;
	Wed, 15 Oct 2008 00:08:27 -0300 (ADT)
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 postgresql.org (Postfix) with ESMTP id 9A56E64FE49
	for <pgsql-general@postgresql.org>;
	Wed, 15 Oct 2008 00:08:26 -0300 (ADT)
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 m9F37qmm008374;
	Tue, 14 Oct 2008 23:07:52 -0400 (EDT)
To: Gregory Stark <stark@enterprisedb.com>
cc: Greg Smith <gsmith@gregsmith.com>, Kevin Murphy <murphy@genome.chop.edu>,
	pgsql-general@postgresql.org
Subject: Re: Drupal and PostgreSQL - performance issues? 
In-reply-to: <87od1mbpsv.fsf@oxford.xeocode.com> 
References: <2434A118-CEFA-43A9-BA88-006EC1F80326@hoegh.org>
	<200810122214.53558.uwe@oss4u.com>
	<20081013090228.248a665f@dawn.webthatworks.it>
	<e7e0a2570810131945x1bbf10b8r67c0ac2a340b436f@mail.gmail.com>
	<20081014114011.0ebe495a@dawn.webthatworks.it>
	<3250B5B6-B507-4E79-BAF0-E98B73E9FED9@hoegh.org>
	<Pine.GSO.4.64.0810140942010.28645@westnet.com>
	<48F4B3C2.1050805@genome.chop.edu>
	<Pine.GSO.4.64.0810141747240.5472@westnet.com>
	<87od1mbpsv.fsf@oxford.xeocode.com>
Comments: In-reply-to Gregory Stark <stark@enterprisedb.com>
	message dated "Wed, 15 Oct 2008 02:38:40 +0100"
Date: Tue, 14 Oct 2008 23:07:52 -0400
Message-ID: <8373.1224040072@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=0 tagged_above=0 required=5 tests=none
X-Spam-Level: 
X-Archive-Number: 200810/590
X-Sequence-Number: 138839

Gregory Stark <stark@enterprisedb.com> writes:
> Greg Smith <gsmith@gregsmith.com> writes:
>> DB2 has automatically updated the "shmmax" kernel
>> parameter from "33554432" to the recommended value "268435456".

> This seems like a bogus thing for an application to do though. The Redhat
> people seem happy with the idea but I'm pretty sure it would violate several
> Debian packaging rules.

FWIW, I don't think Red Hat would accept it either.

> ISTM the right way to make it go away is to allocate temporary files and mmap
> them instead of using sysv shared memory.

That's a non-starter unless you can point to a different kernel API that
(a) is as portable as SysV and (b) offers the same amount of assistance
towards preventing multiple postmasters in the same data directory.
See many, many previous discussions in -hackers.

			regards, tom lane