On 2014-06-10 10:42:41 -0400, Robert Haas wrote:
> 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.
>
> But the priority is inherited by child processes, so to decrease the
> priority of JUST the postmaster you need to decrease its priority and
> then set the priority of each child back to the original value.
Gurjeet argues for making the absolute value of child processes priority
configurable though? My point is that attacking the problem from that
angle is wrong.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
