On Thursday, June 28, 2012 07:43:16 PM Tom Lane wrote: > Magnus Hagander <mag...@hagander.net> writes: > > On Thu, Jun 28, 2012 at 7:27 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
