Update documentation about shared memory sizing to reflect current

reality.

1 files changed, 132 insertions, 30 deletions

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index e346ece23ca..3d34835ea15 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.349 2005/08/29 21:38:17 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.350 2005/08/30 00:58:47 tgl Exp $
 -->
 
 <chapter Id="runtime">
@@ -1161,7 +1161,7 @@ SET ENABLE_SEQSCAN TO OFF;
         buffers is only a buffer descriptor, or about 64 bytes, per
         increment in <varname>temp_buffers</>.  However if a buffer is
         actually used an additional 8192 bytes will be consumed for it
-        (or in general <symbol>BLCKSZ</symbol> bytes).
+        (or in general, <symbol>BLCKSZ</symbol> bytes).
        </para>
       </listitem>
      </varlistentry>
@@ -1184,6 +1184,14 @@ SET ENABLE_SEQSCAN TO OFF;
        </para>
 
        <para>
+        If you are not using prepared transactions, this parameter may as
+        well be set to zero.  If you are using them, you will probably
+        want <varname>max_prepared_transactions</varname> to be at least
+        as large as <xref linkend="guc-max-connections">, to avoid unwanted
+        failures at the prepare step.
+       </para>
+
+       <para>
         Increasing this parameter may cause <productname>PostgreSQL</>
         to request more <systemitem class="osname">System V</> shared
         memory than your operating system's default configuration
@@ -1267,6 +1275,32 @@ SET ENABLE_SEQSCAN TO OFF;
      <sect3 id="runtime-config-resource-fsm">
      <title>Free Space Map</title>
 
+     <indexterm>
+      <primary>free space map</primary>
+     </indexterm>
+
+     <para>
+      These parameters control the size of the shared <firstterm>free space
+      map</>, which tracks the locations of unused space in the database.
+      An undersized free space map may cause the database to consume
+      increasing amounts of disk space over time, because free space that
+      is not in the map cannot be re-used; instead <productname>PostgreSQL</>
+      will request more disk space from the operating system when it needs
+      to store new data.
+      The last few lines displayed by a database-wide <command>VACUUM VERBOSE</> 
+      command can help in determining if the current settings are adequate.
+      A <literal>NOTICE</> message is also printed during such an operation
+      if the current settings are too low.
+     </para>
+
+     <para>
+      Increasing these parameters may cause <productname>PostgreSQL</>
+      to request more <systemitem class="osname">System V</> shared
+      memory than your operating system's default configuration
+      allows. See <xref linkend="sysvipc"> for information on how to
+      adjust those parameters, if necessary.
+     </para>
+
      <variablelist>
      <varlistentry id="guc-max-fsm-pages" xreflabel="max_fsm_pages">
       <term><varname>max_fsm_pages</varname> (<type>integer</type>)</term>
@@ -1279,10 +1313,6 @@ SET ENABLE_SEQSCAN TO OFF;
         be tracked in the shared free-space map.  Six bytes of shared memory
         are consumed for each page slot.  This setting must be more than
         16 * <varname>max_fsm_relations</varname>.  The default is 20000.
-        The last few lines of a database-wide <command>VACUUM VERBOSE</> 
-        can help in determining if the the default setting is suitable.  
-        A <literal>NOTICE</> message is also printed during such an operation
-        if the current setting is too low.
         This option can only be set at server start.
        </para>
       </listitem>
@@ -1297,12 +1327,8 @@ SET ENABLE_SEQSCAN TO OFF;
        <para>
         Sets the maximum number of relations (tables and indexes) for which
         free space will be tracked in the shared free-space map.  Roughly
-        fifty bytes of shared memory are consumed for each slot.
+        seventy bytes of shared memory are consumed for each slot.
         The default is 1000.
-        The last few lines of a database-wide <command>VACUUM VERBOSE</>
-        can help in determining if the the default setting is suitable.  
-        A <literal>NOTICE</> message is also printed during such an operation
-        if the current setting is too low.
         This option can only be set at server start.
        </para>
       </listitem>
@@ -1804,9 +1830,18 @@ SET ENABLE_SEQSCAN TO OFF;
        <para>
         Number of disk-page buffers allocated in shared memory for WAL data.
         The default is 8.  The setting need only be large enough to hold
-        the amount of WAL data generated by one typical transaction.
+        the amount of WAL data generated by one typical transaction, since
+        the data is flushed to disk at every transaction commit.
         This option can only be set at server start.
        </para>
+
+       <para>
+        Increasing this parameter may cause <productname>PostgreSQL</>
+        to request more <systemitem class="osname">System V</> shared
+        memory than your operating system's default configuration
+        allows. See <xref linkend="sysvipc"> for information on how to
+        adjust those parameters, if necessary.
+       </para>
       </listitem>
      </varlistentry>
                 
@@ -3952,9 +3987,11 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
       </indexterm>
       <listitem>
        <para>
-        The shared lock table is sized on the assumption that at most
+        The shared lock table is created with room to describe locks on
         <varname>max_locks_per_transaction</varname> *
-        <varname>max_connections</varname> distinct objects will need to
+        (<xref linkend="guc-max-connections"> +
+        <xref linkend="guc-max-prepared-transactions">) objects;
+        hence, no more than this many distinct objects can
         be locked at any one time. (Thus, this parameter's name may be
         confusing: it is not a hard limit on the number of locks taken
         by any one transaction, but rather a maximum average value.)
@@ -3963,6 +4000,14 @@ dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
         have clients that touch many different tables in a single
         transaction. This option can only be set at server start.
        </para>
+
+       <para>
+        Increasing this parameter may cause <productname>PostgreSQL</>
+        to request more <systemitem class="osname">System V</> shared
+        memory than your operating system's default configuration
+        allows. See <xref linkend="sysvipc"> for information on how to
+        adjust those parameters, if necessary.
+       </para>
       </listitem>
      </varlistentry>
 
@@ -4653,9 +4698,10 @@ $ <userinput>postmaster -o '-S 1024 -s'</userinput>
     relevant for <productname>PostgreSQL</>). Almost all modern
     operating systems provide these features, but not all of them have
     them turned on or sufficiently sized by default, especially systems
-    with BSD heritage. (For the <systemitem class="osname">QNX</> and
-    <systemitem class="osname">BeOS</> ports, <productname>PostgreSQL</>
-    provides its own replacement implementation of these facilities.)
+    with BSD heritage. (For the <systemitem class="osname">Windows</>,
+    <systemitem class="osname">QNX</> and <systemitem class="osname">BeOS</>
+    ports, <productname>PostgreSQL</> provides its own replacement
+    implementation of these facilities.)
    </para>
 
    <para>
@@ -4695,8 +4741,7 @@ $ <userinput>postmaster -o '-S 1024 -s'</userinput>
       <row>
        <entry><varname>SHMMAX</></>
        <entry>Maximum size of shared memory segment (bytes)</>
-       <entry>250 kB + 8.2 kB * <xref linkend="guc-shared-buffers"> +
-       14.2 kB * <xref linkend="guc-max-connections"> up to infinity</entry>
+       <entry>at least several megabytes (see text)</entry>
       </row>
 
       <row>
@@ -4764,14 +4809,17 @@ $ <userinput>postmaster -o '-S 1024 -s'</userinput>
     bytes, of a shared memory segment. If you get an error message from
     <function>shmget</> like <errorname>Invalid argument</>, it is
     likely that this limit has been exceeded. The size of the required
-    shared memory segment varies both with the number of requested
-    buffers (<option>-B</> option) and the number of allowed connections
-    (<option>-N</> option), although the former is the most significant.
-    (You can, as a temporary solution, lower these settings to eliminate
-    the failure.) As a rough approximation, you can estimate the
-    required segment size as suggested in <xref
-    linkend="sysvipc-parameters">.  Any error message you might get will
-    contain the size of the failed allocation request.
+    shared memory segment varies depending on several
+    <productname>PostgreSQL</> configuration parameters, as shown in
+    <xref linkend="shared-memory-parameters">.
+    You can, as a temporary solution, lower some of those settings to
+    avoid the failure.  As a rough approximation, you can estimate the
+    required segment size as 500 kB plus the variable amounts shown in
+    the table.  (Any error message you might get will include the exact
+    size of the failed allocation request.)  While it is possible to get
+    <productname>PostgreSQL</> to run with <varname>SHMMAX</> as small as
+    1 MB, you need at least 4 MB for acceptable performance, and desirable
+    settings are in the tens of megabytes.
    </para>
 
    <para>
@@ -4785,7 +4833,7 @@ $ <userinput>postmaster -o '-S 1024 -s'</userinput>
    <para>
     Less likely to cause problems is the minimum size for shared
     memory segments (<varname>SHMMIN</>), which should be at most
-    approximately 256 kB for <productname>PostgreSQL</> (it is
+    approximately 500 kB for <productname>PostgreSQL</> (it is
     usually just 1). The maximum number of segments system-wide
     (<varname>SHMMNI</>) or per-process (<varname>SHMSEG</>) are unlikely
     to cause a problem unless your system has them set to zero.
@@ -4793,8 +4841,8 @@ $ <userinput>postmaster -o '-S 1024 -s'</userinput>
 
    <para>
     <productname>PostgreSQL</> uses one semaphore per allowed connection
-    (<option>-N</> option), in sets of 16.  Each such set will also
-    contain a 17th semaphore which contains a <quote>magic
+    (<xref linkend="guc-max-connections">), in sets of 16.  Each such set will
+    also contain a 17th semaphore which contains a <quote>magic
     number</quote>, to detect collision with semaphore sets used by
     other applications. The maximum number of semaphores in the system
     is set by <varname>SEMMNS</>, which consequently must be at least
@@ -4834,6 +4882,7 @@ $ <userinput>postmaster -o '-S 1024 -s'</userinput>
     for <productname>PostgreSQL</>.
    </para>
 
+
     <variablelist>
 
      <varlistentry>
@@ -5172,6 +5221,59 @@ set semsys:seminfo_semmsl=32
      </varlistentry>
 
     </variablelist>
+
+
+   <table id="shared-memory-parameters">
+    <title>Configuration parameters affecting
+    <productname>PostgreSQL</productname>'s shared memory usage</>
+
+    <tgroup cols="2">
+     <thead>
+      <row>
+       <entry>Name</>
+       <entry>Approximate multiplier (bytes per increment)</>
+      </row>
+     </thead>
+
+     <tbody>
+      <row>
+       <entry><xref linkend="guc-max-connections"></>
+       <entry>400 (but see also <varname>max_locks_per_transaction</>)</entry>
+      </row>
+
+      <row>
+       <entry><xref linkend="guc-max-prepared-transactions"></>
+       <entry>600 (but see also <varname>max_locks_per_transaction</>)</entry>
+      </row>
+
+      <row>
+       <entry><xref linkend="guc-max-locks-per-transaction"></>
+       <entry>220 * (<xref linkend="guc-max-connections"> +
+        <xref linkend="guc-max-prepared-transactions">)</>
+      </row>
+
+      <row>
+       <entry><xref linkend="guc-shared-buffers"></>
+       <entry>8300</>
+      </row>
+
+      <row>
+       <entry><xref linkend="guc-wal-buffers"></>
+       <entry>8200</>
+      </row>
+
+      <row>
+       <entry><xref linkend="guc-max-fsm-relations"></>
+       <entry>70</>
+      </row>
+
+      <row>
+       <entry><xref linkend="guc-max-fsm-pages"></>
+       <entry>6</>
+      </row>
+     </tbody>
+    </tgroup>
+   </table>
   </sect2>