Skip site navigation (1) Skip section navigation (2)

Re: Posix Shared Mem patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Posix Shared Mem patch
Date: 2012-06-28 15:26:00
Message-ID: CA+TgmoaugMTna=Qxua4B3ts=4Pcf57v8=O2rTdwbnmwXcGzRFg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jun 28, 2012 at 10:11 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> ... btw, I rather imagine that Robert has already noticed this, but OS X
> (and presumably other BSDen) spells the flag "MAP_ANON" not
> "MAP_ANONYMOUS".  I also find this rather interesting flag there:
>
>     MAP_HASSEMAPHORE  Notify the kernel that the region may contain sema-
>                       phores and that special handling may be necessary.
>
> By "semaphore" I suspect they mean "spinlock", so we'd better turn this
> flag on where it exists.

Sounds fine to me.  Since no one seems opposed to the basic approach,
and everyone (I assume) will be happier to reduce the impact of
dealing with shared memory limits, I went ahead and committed a
cleaned-up version of the previous patch.  Let's see what the
build-farm thinks.

Assuming things go well, there are a number of follow-on things that
we need to do finish this up:

1. Update the documentation.  I skipped this for now, because I think
that what we write there is going to be heavily dependent on how
portable this turns out to be, which we don't know yet.  Also, it's
not exactly clear to me what the documentation should say if this does
turn out to work everywhere.  Much of section 17.4 will become
irrelevant to most users, but I doubt we'd just want to remove it; it
could still matter for people running EXEC_BACKEND or running many
postmasters on the same machine or, of course, people running on
platforms where this just doesn't work, if there are any.

2. Update the HINT messages when shared memory allocation fails.
Maybe the new most-common-failure mode there will be too many
postmasters running on the same machine?  We might need to wait for
some field reports before adjusting this.

3. Consider adjusting the logic inside initdb.  If this works
everywhere, the code for determining how to set shared_buffers should
become pretty much irrelevant.  Even if it only works some places, we
could add 64MB or 128MB or whatever to the list of values we probe, so
that people won't get quite such a sucky configuration out of the box.
 Of course there's no number here that will be good for everyone.

and of course

4. Fix any platforms that are now horribly broken.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-06-28 15:29:09
Subject: Re: [v9.3] Row-Level Security
Previous:From: Jeff JanesDate: 2012-06-28 15:21:41
Subject: Re: experimental: replace s_lock spinlock code with pthread_mutex on linux

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group