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@gregsmith.com http://www.gregsmith.com Baltimore, MD
