On Thu, Jun 28, 2012 at 10:11 AM, Tom Lane <tgl@sss.pgh.pa.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
goodfor everyone.
and of course
4. Fix any platforms that are now horribly broken.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company