Some editorializing on the Linux memory overcommit docs, from Neil Conway.

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 285fb4db54837e8f4b7ad38684350a2c7bbb8a20..c1a04a82de00568d2fb24dca7001daa3dff4fa86 100644 (file)
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1,5 +1,5 @@
 
 
 
@@ -1294,7 +1294,7 @@ SET ENABLE_SEQSCAN TO OFF;
     
      Unfortunately, there is no well-defined method for determining
      ideal values for the family of cost variables that
-     below. You are encouraged to experiment and share
+     appear below. You are encouraged to experiment and share
      your findings.
     
    
@@ -3267,35 +3267,36 @@ default:\
    Linux Memory Overcommit
 
    
-    Linux kernels of version 2.4.* have a poor default memory
-    overcommit behavior, which can result in the PostgreSQL server
-    (postmaster process) being killed by the
-    kernel if the memory demands of another process cause the system
-    to run out of memory.
+    In Linux 2.4, the default virtual memory behavior is not
+    optimal for PostgreSQL. Because of the
+    way that the kernel implements memory overcommit, the kernel may
+    terminate the PostgreSQL server (the
+    postmaster process) if the memory demands of
+    another process cause the system to run out of virtual memory.
    
 
    
-    If this happens, you will see a kernel message looking like this
-    (consult your system documentation and configuration on where to
-    look for such a message):
+    If this happens, you will see a kernel message that looks like
+    this (consult your system documentation and configuration on where
+    to look for such a message):
 
 Out of Memory: Killed process 12345 (postmaster). 
 
-    And, of course, you will find that your database server has
-    disappeared.
+    This indicates that the postmaster process
+    has been terminated due to memory pressure;
+    PostgreSQL will need to be restarted.
    
 
    
     To avoid this situation, run PostgreSQL
     on a machine where you can be sure that other processes will not
     run the machine out of memory. If your kernel supports the strict
-    and/or paranoid modes of overcommit handling, you can also relieve
-    this problem by altering the system's default behaviour. This can
-    be determined by examining the function
-    vm_enough_memory in the file mm/mmap.c
-    in the kernel source. If this file reveals that the strict and/or
-    paranoid modes are supported by your kernel, turn one of these
-    modes on by using
+    and/or paranoid modes of overcommit handling, you can also relieve this
+    problem by altering the system's default behaviour. This can be
+    determined by examining the function vm_enough_memory
+    in the file mm/mmap.c in the kernel source. If this
+    file reveals that the strict or paranoid modes are supported by
+    your kernel, turn one of these modes on by using
 
 sysctl -w vm.overcommit_memory=2
 
@@ -3304,12 +3305,16 @@ sysctl -w vm.overcommit_memory=2
 sysctl -w vm.overcommit_memory=3
 
     for paranoid mode, or placing an equivalent entry in
-    /etc/sysctl.conf.
+    /etc/sysctl.conf.  For more information on memory
+    overcommit handling and the meaning of these kernel settings,
+    consult the file
+    Documentation/vm/overcommit-accounting in a
+    recent version of the source code for the Linux kernel.
    
 
    
     
-     Using these settings in a kernel which does not support these
+     Using these settings with a kernel which does not support these
      modes will almost certainly increase the danger of the kernel
      killing the database server, rather than reducing it. If in any
      doubt, consult a kernel expert or your kernel vendor.
@@ -3317,15 +3322,12 @@ sysctl -w vm.overcommit_memory=3
    
 
    
-    These modes are expected to be supported in all 2.6 and later
-    kernels. Some vendor 2.4 kernels may also support these modes. It
-    is, however, known that some vendor documents suggest that they
-    support them while examination of the kernel source reveals that
-    they do not.
-   
-
-   
-    Note, you will need enough swap space to cover all your memory needs.
+    The method described above for changing the kernel's overcommit
+    behavior should work with Linux kernel versions 2.6 and later. In addition,
+    some versions of the 2.4 kernel distributed by some vendors may
+    also support this functionality. However, it is known that some
+    vendor documents suggest that they support them while examination
+    of the kernel source reveals that they do not.