From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jonathan Corbet <corbet(at)lwn(dot)net> |
Cc: | Christoph Berg <cb(at)df7cb(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gurjeet Singh <gurjeet(at)singh(dot)im>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: /proc/self/oom_adj is deprecated in newer Linux kernels |
Date: | 2014-07-02 17:08:55 |
Message-ID: | CA+TgmoZaytS_0WrS=tMoAB7BkZ2ob2RuxZ-_NS1ABhWPTQRfNA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 2, 2014 at 9:08 AM, Jonathan Corbet <corbet(at)lwn(dot)net> wrote:
> On Tue, 1 Jul 2014 15:57:25 -0400
> Robert Haas <robertmhaas(at)gmail(dot)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 don't (and can't)
> scan the world for software that might break. OTOH, if somebody were
> to respond to a proposed change by saying "this breaks PostgreSQL," I
> would be amazed if the change were to be merged in that form.
>
> In other words, it's important to scream. There were concerns during
> the last round of messing with the OOM logic, but nobody pointed to
> something that actually broke.
>
> I predict that somebody will certainly try to rewrite the OOM code
> again in the future. The nature of that code is such that it is never
> going to work as well as people would like. But if application
> developers make it clear that they are dependent on the current
> interface working, kernel developers will be constrained to keep it
> working.
Well, of course the reality is that if you don't break some things,
you can never change anything. And clearly we want Linux to be able
to change things, to make them better.
On the flip side, interface changes do cause some pain, and it's not
realistic to expect every software project to monitor LKML.
This one is not really a big deal, though; I think we just need to
keep in mind, as you say, that it might change again.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2014-07-02 17:52:04 | Re: Aggregate function API versus grouping sets |
Previous Message | Tom Lane | 2014-07-02 16:03:49 | Re: Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally. |