Re: /proc/self/oom_adj is deprecated in newer Linux kernels
От | Robert Haas |
---|---|
Тема | Re: /proc/self/oom_adj is deprecated in newer Linux kernels |
Дата | |
Msg-id | CA+TgmoY=5O2Z3UhEYbNcyjzq=ZGLNekESZoKNtPT320WV=doyw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: /proc/self/oom_adj is deprecated in newer Linux kernels (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, Jun 12, 2012 at 1:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Jun 12, 2012 at 12:37 PM, Tom Lane <tgl@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 fork_process.c. > >> I think my position, and the position of the people who responded to >> the original thread, was that it seems like you're architecting a >> kludge when it wouldn't be that hard to architect a nicer solution. > > I'd be the first to agree it's a kluge. But the end result of the > previous discussion was that it wasn't so obvious how to architect > a nicer solution. Nor is there all that much room for people to use a > nicer solution, given that we need help from not just fork_process.c > but the root-privileged startup script (or lately in Fedora it's a > systemd unit script doing the privilege-increasing end of this). Well, I don't think a GUC or two would be such a bad way of doing it, but... > In the short run, if we don't have consensus on this, I'll probably > just carry a Fedora patch like so: > > - int fd = open("/proc/self/oom_adj", O_WRONLY, 0); > + int fd = open("/proc/self/oom_score_adj", O_WRONLY, 0); > > But it seems a tad silly to be carrying such a patch for a block of > code that is only of interest to Linux packagers anyway, and nearly > all such packagers are facing this same issue either now or in the > very near future. ...I also agree with this. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: