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
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
regards, tom lane
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: