Re: Posix Shared Mem patch

On Thursday, June 28, 2012 07:43:16 PM Tom Lane wrote:
> 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 an error 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.
Its also a very good method to get into hard to diagnose OOM situations 
though. Unless the machine is setup very careful and only runs postgres I 
don't think its acceptable to do that.

Andres
-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services