<!--
-$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">
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>
This option can only be set at server start.
</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
<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>
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>
<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>
<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>
</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.)
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>
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>
<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>
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>
<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.
<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
for <productname>PostgreSQL</>.
</para>
+
<variablelist>
<varlistentry>
</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>
#listen_addresses = 'localhost' # what IP interface(s) to listen on;
# defaults to localhost, '*' = any
#port = 5432
-#max_connections = 100 # note: increasing max_connections costs
- # about 500 bytes of shared memory per
- # connection slot, in addition to costs
- # from shared_buffers and
- # max_locks_per_transaction.
+#max_connections = 100
+# note: increasing max_connections costs ~400 bytes of shared memory per
+# connection slot, plus lock space (see max_locks_per_transaction). You
+# might also need to raise shared_buffers to support more connections.
#superuser_reserved_connections = 2
#unix_socket_directory = ''
#unix_socket_group = ''
#shared_buffers = 1000 # min 16 or max_connections*2, 8KB each
#temp_buffers = 1000 # min 100, 8KB each
#max_prepared_transactions = 5 # can be 0 or more
+# note: increasing max_prepared_transactions costs ~600 bytes of shared memory
+# per transaction slot, plus lock space (see max_locks_per_transaction).
#work_mem = 1024 # min 64, size in KB
#maintenance_work_mem = 16384 # min 1024, size in KB
#max_stack_depth = 2048 # min 100, size in KB
# - Free Space Map -
#max_fsm_pages = 20000 # min max_fsm_relations*16, 6 bytes each
-#max_fsm_relations = 1000 # min 100, ~50 bytes each
+#max_fsm_relations = 1000 # min 100, ~70 bytes each
# - Kernel Resource Usage -
#---------------------------------------------------------------------------
#deadlock_timeout = 1000 # in milliseconds
-#max_locks_per_transaction = 64 # min 10, ~200*max_connections
- # bytes each
+#max_locks_per_transaction = 64 # min 10
+# note: each lock table slot uses ~220 bytes of shared memory, and there are
+# max_locks_per_transaction * (max_connections + max_prepared_transactions)
+# lock table slots.
#---------------------------------------------------------------------------