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