Re: /proc/self/oom_adj is deprecated in newer Linux kernels
От | Gurjeet Singh |
---|---|
Тема | Re: /proc/self/oom_adj is deprecated in newer Linux kernels |
Дата | |
Msg-id | CABwTF4XDdYiBQXqj=CKrFXN7x2NiBbVnpHSJG6AVnMBLnLBmLA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: /proc/self/oom_adj is deprecated in newer Linux kernels (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: /proc/self/oom_adj is deprecated in newer Linux kernels
Re: /proc/self/oom_adj is deprecated in newer Linux kernels |
Список | pgsql-hackers |
On Mon, Sep 19, 2011 at 10:18 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@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; which is about as >>> close as you're likely to get to a kernel version test for this. > >> Why is this feature not a run-time configuration variable or at least a >> configure option? It's awfully well hidden now. I doubt a lot of >> people are using this even though they might wish to. > > See the thread in which the feature was designed originally: > http://archives.postgresql.org/pgsql-hackers/2010-01/msg00170.php > > The key point is that to get useful behavior, you need cooperation > between both a root-privileged startup script and the PG executable. > That tends to throw the problem into the domain of packagers, more > than end users, and definitely puts a big crimp in the idea that > run-time configuration of just half of the behavior could be helpful. > So far, no Linux packagers have complained that the design is inadequate > (a position that I also hold when wearing my red fedora) so I do not > feel a need to complicate it further. 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 the solution; except if they go compile their own binaries, which forces them into being packagers. I am not alone in feeling that if Postgres wishes to provide a control over child backend's oom_score_adj, it should be a GUC parameter rather than a compile-time option. Yesterday a customer wanted to leverage this and couldn't because they refuse to maintain their own fork of Postgres code. Please find attached a patch to turn it into a GUC, #ifdef'd by __linux__ macro. Best regards, -- Gurjeet Singh http://gurjeet.singh.im/ EDB www.EnterpriseDB.com
Вложения
В списке pgsql-hackers по дате отправления: