On Tue, Jun 10, 2014 at 1:13 PM, David G Johnston <david.g.johns...@gmail.com> wrote: > Gurjeet Singh-4 wrote >> So the argument that this GUC is a security concern, can be ignored. >> Root user (one with control of start script) still controls the lowest >> badness setting of all Postgres processes. If done at fork_process >> time, the child process simply inherits parent's badness setting. > > The counter point here is that the postmaster can be set to "no kill" and
Only the root user can do that, since he/she has control over the start script. All that the DBA could do with a GUC is to set backends' badness worse than postmaster's, but bot better. > the >= condition allows for children to achieve the same while it is our > explicit intent that the children be strictly > parent. I don't think anyone argued for that behaviour. > To that end, should the adjustment value be provided as an offset to the > postmasters instead of an absolute value - and disallow <= zero offset > values in the process? Seems unnecessary, given current knowledge. > I get and generally agree with the environment variable proposal and it's > stated goal to restrict whom can makes changes. But how much less cost does > an environment variable have than a GUC if one GUC argument is still its > maintenance overhead? Having it as a GUC would have meant that two entities are required to get the configuration right: one who controls start scripts, and the other who controls GUC settings. With the environment variable approach, a root user alone can control the behaviour like so in start script: echo -200 > /proc/self/oom_score_adj export PG_OOM_ADJUST_FILE=oom_score_adj export PG_OOM_ADJUST_VALUE=-100 Best regards, -- Gurjeet Singh http://gurjeet.singh.im/ EDB www.EnterpriseDB.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
