On 2014-06-10 11:35:23 -0400, Robert Haas wrote: > > Because it would convert the intended behavior (postmaster and only > > postmaster is exempt from OOM kill) into a situation where possibly > > all of the database processes are exempt from OOM kill, at the whim > > of somebody who should not have the privilege to decide that. > > Gurjeet already refused that argument.
Only that he was wrong: ~# echo -500 > /proc/$BASHPID/oom_score_adj ~# su andres ~$ echo -1000 > /proc/$BASHPID/oom_score_adj bash: echo: write error: Permission denied # so I can't decrease the likelihood ~$ echo -400 > /proc/$BASHPID/oom_score_adj # but I can increase it ~$ echo -500 > /proc/$BASHPID/oom_score_adj # but also *reset* it Since we have to do the adjustment after the fork - otherwise the postmaster would be vulnerable for a time - normal backends can reset their score. > Apparently, the child > processes can only increase their chance of being OOM-killed, not > decrease it, so you have this exactly backwards: right now, an > individual system administrator can exempt all of the database > processes from OOM kill, but cannot exempt the postmaster alone. Well, if you compile postgres with the #define it'll reset the likelihood after the fork? That's the reset? Or do you mean without compiling postgres with the option? Greetings, Andres Freund -- 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
