Excerpts from Tom Lane's message of vie sep 16 13:37:46 -0300 2011: > Greg Stark <st...@mit.edu> writes: > > On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Does anyone want > >> to argue for doing something more complicated, and if so what exactly? > > > Well there's no harm trying to write to oom_score_adj and if that > > fails with EEXISTS trying to write to oom_adj. > > Well, (1) what value are you going to write (they need to be different > for the two files), and (2) the main point of the exercise, at present, > is to avoid kernel log messages. I'm not sure that trying to create > random files under /proc isn't going to draw bleats in the kernel log.
I guess the question is what semantics the new code has. In the old badness() world, child processes inherited the oom_adj value of its parent. What the code in fork_process was used for was resetting the value back to 0 (meaning "kernel is allowed to kill this process on OOM"), so that you could set the oom_adj in the start script for postmaster (to a value meaning "never kill this one"), and the backends would see their values reset to zero. The new oom_score_adj has a scale of -1000 to +1000, with zero being neutral and -1000 being "never kill". So what we want to do here in most cases, it seems, is set the value to zero whether it's oom_adj or oom_score_adj -- assuming the new code is still causing children processes to inherit the "adj" value from the parent. Now the problem is that we have defined the LINUX_OOM_ADJ symbol as meaning the value we're going to write. Maybe this wasn't the best choice. I mean, it's very flexible, but it doesn't seem to offer any benefit over a plain boolean choice. Is your proposal to create a new LINUX_OOM_SCORE_ADJ cpp symbol with the same semantics? The most thorough documentation on this option seems to be this commit: https://github.com/mirrors/linux-2.6/commit/a63d83f427fbce97a6cea0db2e64b0eb8435cd10#include/linux/oom.h -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
