Robert Haas <robertmh...@gmail.com> writes:
> Well, clearly, somebody hasn't got it right, or there wouldn't be this
> complaint. I'll grant you that "somebody" may be EnterpriseDB's own
> packaging in this instance, but I wouldn't like to bet that no one
> else has ever got this wrong nor ever will. Peter asked upthread why
> this wasn't a GUC with the comment that "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." I think that's quite right, and note that
> Peter is in no way affiliated with EnterpriseDB and made that comment
> (rather presciently) long before Gurjeet's recent report.
I'd be okay with a configure option, if you think that would make this
issue more visible to packagers. It's delegating the responsibility to
the DBA level that I'm unhappy about.
>> Because it would convert the intended behavior (postmaster and only
>> postmaster is exempt from OOM kill) into a situation where possibly
>> all of the database processes are exempt from OOM kill, at the whim
>> of somebody who should not have the privilege to decide that.
> Gurjeet already refused that argument.
He can refuse it all he likes, but that doesn't make his opinion correct.
> How about using an environment variable? It seems to me that would
> address the concern about DBAs without shell access. They might be
> able to frob GUCs, but presumably not the postmaster's starting
> environment.
Hmmm ... yeah, that might work. It would solve the problem I'm worried
about, which is making sure that the startup script has control of what
happens.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
