On Tue, Jun 10, 2014 at 11:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Jun 10, 2014 at 11:29 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> If you think your users might want to give the postmaster OOM-exemption,
>>> why don't you just activate the existing code when you build? Resetting
>>> the OOM setting to zero is safe whether or not the startup script did
>>> anything to the postmaster's setting.
>
>> The whole scenario here is that the user *doesn't want to recompile*.
>
> Yeah, I understood that. The question is why EDB isn't satisfied to just
> add "-DLINUX_OOM_ADJ=0" to their build options, but instead would like to
> dump a bunch of uncertainty on other packagers who might not like the
> implications of a GUC.
Well, I think we should do that, too, and I'm going to propose it to
Dave & team. If we're not already doing the right thing here (and I
don't know off-hand whether we are), then that is definitely our issue
to fix and there's no reason to change PostgreSQL on that account.
But I think the point is that this is a pretty subtle and
well-concealed thing which a PostgreSQL packager might fail to do
correctly in every instance - or where an individual user might want
to install a different policy than whatever the packager's default is.
Making that easy to do without recompiling seems to me to be a general
good. Magnus once commented to me that every GUC which is
PGC_POSTMASTER is a bug - "perhaps not an easy bug to fix, but a bug
all the same" (his words), because requiring people to restart the
postmaster to change settings is often problematic. I think this is
even more true of recompiling. IMO, it should be an explicit goal of
the project to make reconfiguration of an already-installed system -
perhaps even already in production - as easy as possible. We will
doubtless fail to achieve perfection but that doesn't mean we
shouldn't try.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
