On Fri, 29 Aug 2008, Bill Moran wrote:
First off, the solution of making the postmaster immune to the OOM killer seems better than disabling overcommit to me anyway
I really side with Craig James here that the right thing to do here is to turn off overcommit altogether. While it's possible that servers being used for things other than PostgreSQL might need it, I feel that's a rare case that's really hostile to the database environment and it shouldn't be encouraged.
I don't understand why we should avoid making the PG documentation as comprehensive as possible
The main problem here is that this whole area is a moving target. To really document this properly, you end up going through this messy exercise where you have to create a table showing what kernel versions support the option you're trying to document. And even that varies based on what distribution you're dealing with. Just because you know when something showed up in the mainline kernel, without some research you can't really know for sure when RedHat or SuSE slipped that into their kernel--sometimes they lead mainline, sometimes they lag.
The PG documentation shies away from mentioning thing that are so volatile, because the expectation is that people will still be using that as a reference many years from now. For all we know, 2.6.27 will come out and make any documentation about this obscure oomadj feature obsolete. I think the only thing that might make sense here is to write something on the Wiki that goes over in what situations you might run with overcommit enabled, how that can interact with database operation, and then tries to address the version issue. Then that can be updated as new versions are released so it stays current. If that's available with a stable URL, it might make sense to point to it in the documentation near where turning overcommit off is mentioned.
-- * Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD
