Gregory Williamson wrote:
>Bill Moran wrote:
>> In response to Greg Smith <gsmith@gregsmith.com>:
>>
>> <snipped...>
>>
>> I don't know, Greg. First off, the solution of making the postmaster
>> immune to the OOM killer seems better than disabling overcommit to me
>> anyway; and secondly, I don't understand why we should avoid making
>> the PG documentation as comprehensive as possible, which seems to be
>> what you are saying: "we shouldn't make the PG documentation too
>> comprehensive, because then it will get very big"
> I think it would be a hopeless morass for PostgreSQL to try to document
> each evolution of each OS it runs under; the general caveat seems
>fine, although perhaps adding something to the effect of "search the
> archives for possible specifics" might be in order. But tracking postgres's
> own shifts and requirements seems daunting enough w/out adding in
> endless flavours of different OSs.
> My $0.02 worth ...
In some aspects I agree, however in this specific case I think the docs should include the details about options to protect the postmaster from the OOM killer.
So far I’ve seen three basic solutions to this problem:
(1) Disabling overcommit
(2) Be generous with swap space
(3) Protect postmaster from the OOM killer
As we’ve seen so far, there is not one solution that makes everybody happy. Each option has its merits and downsides. Personally, I think in this case the docs should present all 3 options, perhaps in a Linux specific note or section, so each DBA can decide for themselves the appropriate method.
Going one step further, I’m thinking making the third option the default on Linux systems might not be a bad thing either. And, if that is done, the docs definitely need to contain information about it.
Another couple of cents in the pot…
Greg