On Wed, Sep 25, 2013 at 8:00 AM, Greg Stark st...@mit.edu wrote:
On Wed, Sep 25, 2013 at 12:15 AM, Daniel Farina dan...@heroku.com wrote:
Enable the memcg OOM killer only for user faults, where it's really the
only option available.
Is this really a big deal? I would expect most faults to
On Wed, Sep 25, 2013 at 12:15 AM, Daniel Farina dan...@heroku.com wrote:
Enable the memcg OOM killer only for user faults, where it's really the
only option available.
Is this really a big deal? I would expect most faults to be user faults.
It's certainly a big deal that we need to ensure we
All,
I've send kernel.org a message that we're keen on seeing these changes
become committed.
BTW, in the future if anyone sees kernel.org contemplating a patch which
helps or hurts Postgres, don't hesiate to speak up to them. They don't
get nearly enough feedback from DB developers.
--
Josh
All,
I've send kernel.org a message that we're keen on seeing these changes
get committed.
BTW, in the future if anyone sees kernel.org contemplating a patch which
helps or hurts Postgres, don't hesiate to speak up to them. They don't
get nearly enough feedback from DB developers.
--
Josh
On Sep 24, 2013 10:12 AM, Josh Berkus j...@agliodbs.com wrote:
All,
I've send kernel.org a message that we're keen on seeing these changes
become committed.
I thought it was merged already in 3.12. There are a few related
patches, but here's one:
commit
On Wed, Sep 18, 2013 at 10:09 PM, Daniel Farina dan...@heroku.com wrote:
I'm not sure how many of you have been tracking this but courtesy of
lwn.net I have learned that it seems that the OOM killer behavior in
Linux 3.12 will be significantly different. And by description, it
sounds like an
On Thu, Sep 19, 2013 at 9:12 AM, Robert Haas robertmh...@gmail.com wrote:
But, naturally, that will not be a problem
since all user-space code diligently checks the return status of every
system call and responds with well-tested error-handling code when
things go wrong.
That just short
On Thu, Sep 19, 2013 at 11:30 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Thu, Sep 19, 2013 at 9:12 AM, Robert Haas robertmh...@gmail.com wrote:
But, naturally, that will not be a problem
since all user-space code diligently checks the return status of every
system call and responds with
On 2013-09-19 18:23:07 +0200, Dimitri Fontaine wrote:
I've been told at several instances that this has been made for the JVM
and other such programs that want to allocate huge amount of memory even
if they don't really intend to use it.
That's not really related - what you describe is memory
On Thu, Sep 19, 2013 at 12:02 PM, Andres Freund and...@2ndquadrant.com wrote:
The problem is that it's not just about malloc() (aka brk() and
mmap()) and friends. It's about many of the other systemcalls. Like
e.g. send() to name one of the more likely ones.
*shrug*
If you're using for send()
On 2013-09-19 11:49:05 -0400, Robert Haas wrote:
On Thu, Sep 19, 2013 at 11:30 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Thu, Sep 19, 2013 at 9:12 AM, Robert Haas robertmh...@gmail.com wrote:
But, naturally, that will not be a problem
since all user-space code diligently checks the
Andres Freund and...@2ndquadrant.com writes:
What has changed is how to react to situations where memory has been
overcommitted but is now actually needed.
Sure. You either have a failure at malloc() or usage, over commit is all
about never failing at malloc(), but now you have to deal with OOM
Robert Haas robertmh...@gmail.com writes:
I laughed, too, but the reality is that at least as far as PG is
concerned it's probably a truthful statement, and if it isn't, nobody
here is likely to complain about having to fix it. Yeah, there's a
lot of other code out there not as well written
I'm not sure how many of you have been tracking this but courtesy of
lwn.net I have learned that it seems that the OOM killer behavior in
Linux 3.12 will be significantly different. And by description, it
sounds like an improvement. I thought some people reading -hackers
might be interested.
14 matches
Mail list logo
