On Tue, Jun 10, 2014 at 10:32 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-06-10 07:56:01 -0400, Gurjeet Singh wrote:
>> Providing it as GUC would have given end users both the peices, but
>> with a compile-time option they have only one half of the solution;
>> except if they go compile their own binaries, which forces them into
>> being packagers.
>>
>> I am not alone in feeling that if Postgres wishes to provide a control
>> over child backend's oom_score_adj, it should be a GUC parameter
>> rather than a compile-time option. Yesterday a customer wanted to
>> leverage this and couldn't because they refuse to maintain their own
>> fork of Postgres code.
>
> Independent of the rest of the discussion, I think there's one more
> point: Trying to keep your system stable by *increasing* the priority of
> normal backends is a bad idea. If you system gets into OOM land you need
> to fix that, not whack who gets killed around.
> The reason it makes sense to increase the priority of the postmaster is
> that that *does* increase the stability by cleaning up resources and
> restarting everything.
As it stands right now, a user can decrease the likelyhood of
Postmaster being killed by adjusting the start script, but that
decreases the likelyhood of al the child processes, too, making the
Postmaster just as likely as a kill-candidate, maybe even higher
because it's the parent, as any backend.
This patch gives the user a control to let the backend's likelyhood of
being killed be different/higher than that of the postmaster.
The users were already capable of doing that, but were required to
custom-compile Postgres to get the benefits. This patch just removes
that requirement.
Best regards,
--
Gurjeet Singh http://gurjeet.singh.im/
EDB www.EnterpriseDB.com