Re: Posix Shared Mem patch - Mailing list pgsql-hackers

On 28 June 2012 16:26, Robert Haas <robertmhaas@gmail.com> wrote:
> 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 good for everyone.
>
> and of course
>
> 4. Fix any platforms that are now horribly broken.

On 64-bit Linux, if I allocate more shared buffers than the system is
capable of reserving, it doesn't start.  This is expected, but there's
no error logged anywhere (actually, nothing logged at all), and the
postmaster.pid file is left behind after this failure.

--
Thom