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

From Tom Lane
Subject Re: Posix Shared Mem patch
Date
Msg-id 24864.1340905396@sss.pgh.pa.us
Whole thread Raw
In response to Re: Posix Shared Mem patch  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Posix Shared Mem patch  (Andres Freund <andres@2ndquadrant.com>)
Re: Posix Shared Mem patch  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> On Thu, Jun 28, 2012 at 7:27 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> On Thursday, June 28, 2012 07:19:46 PM Magnus Hagander wrote:
>>> What happens if you mlock() it into memory - does that fail quickly?
>>> Is that not something we might want to do *anyway*?

>> You normally can only mlock() mminor amounts of memory without changing
>> settings. Requiring to change that setting (aside that mlocking would be a bad
>> idea imo) would run contrary to the point of the patch, wouldn't it? ;)

> It would. I wasn't aware of that limitation :)

The OSX man page says that mlock should give EAGAIN for a permissions
failure (ie, exceeding the rlimit) but
    [ENOMEM]           Some portion of the indicated address range is not                       allocated.  There was
anerror faulting/mapping a                       page.
 

It might be helpful to try mlock (if available, which it isn't
everywhere) and complain about ENOMEM but not other errors.  If course,
if the kernel checks rlimit first, we won't learn anything ...

I think it *would* be a good idea to mlock if we could.  Setting shmem
large enough that it swaps has always been horrible for performance,
and in sysv-land there's no way to prevent that.  But we can't error
out on permissions failure.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Patch-2 (2-move-continuation-record-to-page-header.patch) WAL Format Changes
Next
From: Andres Freund
Date:
Subject: Re: Posix Shared Mem patch