To: Peter Eisentraut <peter_e@gmx.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: /proc/self/oom_adj is deprecated in newer Linux kernels 
In-reply-to: <1316355543.12186.9.camel@vanquo.pezone.net> 
References: <29121.1316185073@sss.pgh.pa.us>
	<1316355543.12186.9.camel@vanquo.pezone.net>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
	message dated "Sun, 18 Sep 2011 17:19:02 +0300"
Date: Sun, 18 Sep 2011 12:21:08 -0400
Message-ID: <15953.1316362868@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@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 we do that, then it would be up to the packager whether to #define
>> LINUX_OOM_ADJ or LINUX_OOM_SCORE_ADJ or both depending on the behavior
>> he wants.

> There are lots of reasons why that won't work: backports, forward ports,
> derivatives, custom kernels, distribution upgrades, virtual hosting.

[ shrug... ]  These are all hypothetical reasons.  A packager who
foresaw needing that could just turn on both write attempts, or for that
matter patch the code to do whatever else he saw fit.  In practice,
we've not had requests for anything significantly smarter than what is
there.

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; which is about as
close as you're likely to get to a kernel version test for this.

			regards, tom lane