On Tue, Jun 10, 2014 at 1:13 PM, David G Johnston
<david.g.johnston@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
