Re: Tom Lane 2014-07-01 20654.1404247...@sss.pgh.pa.us
Yeah, I'm unexcited about this proposal. In any case, given the two
existing APIs we have to deal with, allowing PG_OOM_ADJUST_VALUE to
default to 0 is sane in both APIs but a default for the file name
can work for only one.
Nod.
Fair
On Tue, 1 Jul 2014 15:57:25 -0400
Robert Haas robertmh...@gmail.com wrote:
Of course, we have no guarantee that the Linux kernel guys won't
change this again. Apparently we don't break userspace is a
somewhat selectively-enforced principle.
It's selectively enforced in that kernel developers
Christoph Berg c...@df7cb.de writes:
Re: Tom Lane 2014-07-01 20654.1404247...@sss.pgh.pa.us
Fair enough. I went for a minimum-change approach when hacking that
script, but we could change it some more in the name of readability.
Will do something about that.
Thanks, it's much nicer now.
On Wed, Jul 2, 2014 at 9:08 AM, Jonathan Corbet cor...@lwn.net wrote:
On Tue, 1 Jul 2014 15:57:25 -0400
Robert Haas robertmh...@gmail.com wrote:
Of course, we have no guarantee that the Linux kernel guys won't
change this again. Apparently we don't break userspace is a
somewhat
Re: Tom Lane 2014-06-23 17054.1403542...@sss.pgh.pa.us
While I'd love to reduce the number of future installations without
this fix in place, I respect the decision to honor project policy. At
the same time, this change does not break anything. It introduces new
environment variables which
On Tue, Jul 1, 2014 at 8:22 AM, Christoph Berg c...@df7cb.de wrote:
Re: Tom Lane 2014-06-23 17054.1403542...@sss.pgh.pa.us
While I'd love to reduce the number of future installations without
this fix in place, I respect the decision to honor project policy. At
the same time, this change
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 1, 2014 at 8:22 AM, Christoph Berg c...@df7cb.de wrote:
I have two comments on the patch:
The choice to make the behavior depend first on PG_OOM_ADJUST_FILE and
only secondly on PG_OOM_ADJUST_VALUE seems the wrong way round to me.
Of
On Wed, Jun 18, 2014 at 8:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh gurj...@singh.im writes:
Please find attached the patch. It includes the doc changes as well.
Applied with some editorialization.
Thanks!
would it be possible to include this in 9.4 as well?
Best regards,
--
Gurjeet Singh gurj...@singh.im writes:
would it be possible to include this in 9.4 as well?
While this is clearly an improvement over what we had before, it's
impossible to argue that it's a bug fix, and we are way past the 9.4
feature freeze deadline. In particular, packagers who've already
On Mon, Jun 23, 2014 at 11:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh gurj...@singh.im writes:
would it be possible to include this in 9.4 as well?
While this is clearly an improvement over what we had before, it's
impossible to argue that it's a bug fix, and we are way past the
Gurjeet Singh gurj...@singh.im writes:
On Mon, Jun 23, 2014 at 11:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
While this is clearly an improvement over what we had before, it's
impossible to argue that it's a bug fix, and we are way past the 9.4
feature freeze deadline. In particular, packagers
On Mon, Jun 23, 2014 at 12:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh gurj...@singh.im writes:
While I'd love to reduce the number of future installations without
this fix in place, I respect the decision to honor project policy. At
the same time, this change does not break
Gurjeet Singh gurj...@singh.im writes:
On Tue, Jun 10, 2014 at 12:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we're going to do this, I would say that we should also take the
opportunity to get out from under the question of which kernel API
we're dealing with. So perhaps a design like this:
Gurjeet Singh gurj...@singh.im writes:
Please find attached the patch. It includes the doc changes as well.
What exactly is the point of the static state you added here? There
is no situation where that could possibly be useful, because this
code is executed at most once per process, and not at
On Tue, Jun 10, 2014 at 12:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If we're going to do this, I would say that we should also take the
opportunity to get out from under the question of which kernel API
we're dealing with. So perhaps a design like this:
1. If the environment variable
On Mon, Sep 19, 2011 at 10:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On sön, 2011-09-18 at 12:21 -0400, Tom Lane wrote:
But having said that, it wouldn't be very hard to arrange things so that
if you did have both symbols defined, the code would only
Gurjeet Singh gurj...@singh.im writes:
Startup scripts are not solely in the domain of packagers. End users
can also be expected to develop/edit their own startup scripts.
Providing it as GUC would have given end users both the peices, but
with a compile-time option they have only one half of
On Tue, Jun 10, 2014 at 10:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh gurj...@singh.im writes:
Startup scripts are not solely in the domain of packagers. End users
can also be expected to develop/edit their own startup scripts.
Providing it as GUC would have given end users both
On Tue, Jun 10, 2014 at 10:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh gurj...@singh.im writes:
Startup scripts are not solely in the domain of packagers. End users
can also be expected to develop/edit their own startup scripts.
Providing it as GUC would have given end users both
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
On Tue, Jun 10, 2014 at 10:32 AM, Andres Freund and...@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
On Tue, Jun 10, 2014 at 10:32 AM, Andres Freund and...@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
On 2014-06-10 10:42:41 -0400, Robert Haas wrote:
On Tue, Jun 10, 2014 at 10:32 AM, Andres Freund and...@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
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 10, 2014 at 10:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't find that this argument holds any water at all. Anyone who's
developing their own start script can be expected to manage recompiling
Postgres.
Huh? Lots of people install
On Tue, Jun 10, 2014 at 10:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 10, 2014 at 10:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't find that this argument holds any water at all. Anyone who's
developing their own start script can be
Andres Freund and...@2ndquadrant.com writes:
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
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 10, 2014 at 10:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So? The RPM packager could probably be expected to have compiled with the
oom-adjust-reset option enabled. If not, why aren't these people lobbying
the packager to meet their
Andres Freund and...@2ndquadrant.com writes:
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
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-10 11:04:52 -0400, Tom Lane wrote:
But anyway, yeah, the point of this feature is that the OOM priority
of the postmaster, and *only* the postmaster, should be raised. Allowing
unprivileged people to break that is not attractive on any
On 2014-06-10 11:14:43 -0400, Tom Lane wrote:
Sure, but what's that have to do with this? Any Red Hat or PGDG RPM will
come with this code already enabled in the build, so there is no need for
anyone to have a GUC to play around with the behavior.
That's imo a fair point. Unless I
Gurjeet Singh gurj...@singh.im writes:
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
On 2014-06-10 11:20:28 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-10 11:04:52 -0400, Tom Lane wrote:
But anyway, yeah, the point of this feature is that the OOM priority
of the postmaster, and *only* the postmaster, should be raised. Allowing
On Tue, Jun 10, 2014 at 11:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 10, 2014 at 10:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
So? The RPM packager could probably be expected to have compiled with the
oom-adjust-reset option enabled. If
On Tue, Jun 10, 2014 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
This patch gives the user a control to let the backend's likelyhood of
being killed be different/higher than that of the postmaster.
If you think your users might want to give the postmaster OOM-exemption,
why don't you just
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-10 11:14:43 -0400, Tom Lane 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
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
On Tue, Jun 10, 2014 at 11:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
In my view, the root-owned startup script grants OOM exemption to
the postmaster because it *knows* that the postmaster's children
will drop the exemption. If that trust can be violated because some
clueless DBA decided to
Robert Haas robertmh...@gmail.com writes:
Well, clearly, somebody hasn't got it right, or there wouldn't be this
complaint. I'll grant you that somebody may be EnterpriseDB's own
packaging in this instance, but I wouldn't like to bet that no one
else has ever got this wrong nor ever will.
On 2014-06-10 11:40:25 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-10 11:14:43 -0400, Tom Lane 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
On Tue, Jun 10, 2014 at 11:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'd be okay with a configure option, if you think that would make this
issue more visible to packagers. It's delegating the responsibility to
the DBA level that I'm unhappy about.
[...]
How about using an environment
and...@anarazel.de (Andres Freund) writes:
On 2014-06-10 11:20:28 -0400, Tom Lane wrote:
Maybe I'm mistaken, but I thought once the fork_process code has reset our
process's setting to zero it's not possible to lower it again (without
privileges we'd not have).
No, doesn't look that way.
On Tue, Jun 10, 2014 at 11:24 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-10 11:14:43 -0400, Tom Lane wrote:
Sure, but what's that have to do with this? Any Red Hat or PGDG RPM will
come with this code already enabled in the build, so there is no need for
anyone to have a GUC
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 10, 2014 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If you think your users might want to give the postmaster OOM-exemption,
why don't you just activate the existing code when you build? Resetting
the OOM setting to zero is safe
On 2014-06-10 11:52:17 -0400, Tom Lane wrote:
and...@anarazel.de (Andres Freund) writes:
On 2014-06-10 11:20:28 -0400, Tom Lane wrote:
Maybe I'm mistaken, but I thought once the fork_process code has reset our
process's setting to zero it's not possible to lower it again (without
On Tue, Jun 10, 2014 at 11:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
and...@anarazel.de (Andres Freund) writes:
On 2014-06-10 11:20:28 -0400, Tom Lane wrote:
Maybe I'm mistaken, but I thought once the fork_process code has reset our
process's setting to zero it's not possible to lower it again
Gurjeet Singh gurj...@singh.im writes:
On Tue, Jun 10, 2014 at 11:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert's idea of having the start script set an environment variable to
control the OOM adjustment reset seems like it would satisfy my concern.
I'm fine with this solution. Should this
On Tue, Jun 10, 2014 at 11:56 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 10, 2014 at 11:29 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If you think your users might want to give the postmaster OOM-exemption,
why don't you just activate the existing
In short:
I can accept the idea that picking reasonable specific values is impossible
so let's just ensure that children are always killed before the parent
(basically the default behavior). If you then say that any system that is
capable of implementing that rule should have it set then leaving
On 06/10/2014 07:02 AM, Tom Lane wrote:
Gurjeet Singh gurj...@singh.im writes:
Startup scripts are not solely in the domain of packagers. End users
can also be expected to develop/edit their own startup scripts.
Providing it as GUC would have given end users both the peices, but
with a
Gurjeet Singh-4 wrote
Even if the clueless DBA tries to set the oom_score_adj below that of
Postmaster, Linux kernel prevents that from being done. I demonstrate
that in the below screen share. I used GUC as well as plain command
line to try and set a child's badness (oom_score_adj) to be
On Jun 10, 2014 7:05 PM, Joshua D. Drake j...@commandprompt.com wrote:
On 06/10/2014 07:02 AM, Tom Lane wrote:
Gurjeet Singh gurj...@singh.im writes:
Startup scripts are not solely in the domain of packagers. End users
can also be expected to develop/edit their own startup scripts.
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
I was reminded today that we still haven't done anything about this:
Tom Lane t...@sss.pgh.pa.us writes:
While testing 9.1 RPMs on Fedora 15 (2.6.40 kernel), I notice
messages like these in the kernel log:
Sep 11 13:38:56 rhl kernel: [ 415.308092] postgres (18040):
/proc/18040/oom_adj is
On Tue, Jun 12, 2012 at 12:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I was reminded today that we still haven't done anything about this:
Tom Lane t...@sss.pgh.pa.us writes:
While testing 9.1 RPMs on Fedora 15 (2.6.40 kernel), I notice
messages like these in the kernel log:
Sep 11 13:38:56
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 12, 2012 at 12:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I still think it's sufficient to do what I suggested initially:
... The simplest, least risky change that I can think of is to
copy-and-paste the relevant #ifdef code block in
On Tue, Jun 12, 2012 at 1:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 12, 2012 at 12:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I still think it's sufficient to do what I suggested initially:
... The simplest, least risky change that I can
On sön, 2011-09-18 at 12:21 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On fre, 2011-09-16 at 10:57 -0400, Tom Lane wrote:
So it looks like it behooves us to cater for oom_score_adj in the
future. The simplest, least risky change that I can think of is to
Peter Eisentraut pete...@gmx.net writes:
On sön, 2011-09-18 at 12:21 -0400, Tom Lane wrote:
But having said that, it wouldn't be very hard to arrange things so that
if you did have both symbols defined, the code would only attempt to
write oom_adj if it had failed to write oom_score_adj;
On fre, 2011-09-16 at 10:57 -0400, Tom Lane wrote:
So it looks like it behooves us to cater for oom_score_adj in the
future. The simplest, least risky change that I can think of is to
copy-and-paste the relevant #ifdef code block in fork_process.c.
If we do that, then it would be up to the
Peter Eisentraut pete...@gmx.net writes:
On fre, 2011-09-16 at 10:57 -0400, Tom Lane wrote:
So it looks like it behooves us to cater for oom_score_adj in the
future. The simplest, least risky change that I can think of is to
copy-and-paste the relevant #ifdef code block in fork_process.c.
If
On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Does anyone want
to argue for doing something more complicated, and if so what exactly?
Well there's no harm trying to write to oom_score_adj and if that
fails with EEXISTS trying to write to oom_adj.
--
greg
--
Sent via
Greg Stark st...@mit.edu writes:
On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Does anyone want
to argue for doing something more complicated, and if so what exactly?
Well there's no harm trying to write to oom_score_adj and if that
fails with EEXISTS trying to write to
Excerpts from Tom Lane's message of vie sep 16 13:37:46 -0300 2011:
Greg Stark st...@mit.edu writes:
On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Does anyone want
to argue for doing something more complicated, and if so what exactly?
Well there's no harm trying
Alvaro Herrera alvhe...@commandprompt.com writes:
Now the problem is that we have defined the LINUX_OOM_ADJ symbol as
meaning the value we're going to write. Maybe this wasn't the best
choice. I mean, it's very flexible, but it doesn't seem to offer any
benefit over a plain boolean choice.
On Fri, Sep 16, 2011 at 10:37, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@mit.edu writes:
On Fri, Sep 16, 2011 at 3:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Does anyone want
to argue for doing something more complicated, and if so what exactly?
Well there's no harm trying to write
65 matches
Mail list logo
