In short: I can accept the idea that picking reasonable specific values is impossible so let's just ensure that children are always killed before the parent (basically the default behavior). If you then say that any system that is capable of implementing that rule should have it set then leaving it unexposed makes sense. That line of thought does not require the abstract cost of a GUC to factor into the equation.
However, in considering system configuration and concurrently running processes.... Tom Lane-2 wrote > Extra GUCs do not have zero cost, especially not ones that are as > complicated-to-explain as this would be. The explain factor does little for me since if given a reasonable default the GUC can be ignored until a problem manifests. At that point not having a GUC makes resolving the problem require someone to stop using packaging and instead compile their own source. This results in a poor user experience. So, if someone where to provide a complete patch that introduced a GUC to enable/disable as well as set priorities - to include documentation and reasonable postgresql.conf defaults - what specific ongoing GUC costs would prevent applying said patch? You mention a security hazard but that is not a cost of GUCs generally but this one specifically; and one that seems to have been deemed no riskier than other DBA capabilities. Help me understand the cost side of the equation since the benefit side seems clear-cut enough to me. The OOM problem is real and making PostgreSQL fit within the overall memory management architecture of a given server is something that is the responsibility of the system admin in conjunction with the DBA - not us or the packager. I'll buy that because this is a linux issue that the implementation could be packager selectable but given the dynamics of Linux centralizing a reasonable default implementation into core makes sense. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/proc-self-oom-adj-is-deprecated-in-newer-Linux-kernels-tp4810971p5806697.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
