buffers is only a buffer descriptor, or about 64 bytes, per
increment in temp_buffers>. However if a buffer is
actually used an additional 8192 bytes will be consumed for it
- (or in general BLCKSZ bytes).
+ (or in general, BLCKSZ bytes).
This option can only be set at server start.
+ 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 max_prepared_transactions to be at least
+ as large as , to avoid unwanted
+ failures at the prepare step.
+
+
Increasing this parameter may cause
PostgreSQL>
to request more System V> shared
Free Space Map
+
+
+
+ These parameters control the size of the shared 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
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 VACUUM VERBOSE>
+ command can help in determining if the current settings are adequate.
+ A NOTICE> message is also printed during such an operation
+ if the current settings are too low.
+
+
+ Increasing these parameters may cause
PostgreSQL>
+ to request more System V> shared
+ memory than your operating system's default configuration
+ allows. See for information on how to
+ adjust those parameters, if necessary.
+
+
max_fsm_pages (integer)
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 * max_fsm_relations. The default is 20000.
- The last few lines of a database-wide VACUUM VERBOSE>
- can help in determining if the the default setting is suitable.
- A 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.
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 VACUUM VERBOSE>
- can help in determining if the the default setting is suitable.
- A 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.
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.
+
+ Increasing this parameter may cause
PostgreSQL>
+ to request more System V> shared
+ memory than your operating system's default configuration
+ allows. See for information on how to
+ adjust those parameters, if necessary.
+
- The shared lock table is sized on the assumption that at most
+ The shared lock table is created with room to describe locks on
max_locks_per_transaction *
- max_connections distinct objects will need to
+ ( +
+ ) 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.
+
+ Increasing this parameter may cause
PostgreSQL>
+ to request more System V> shared
+ memory than your operating system's default configuration
+ allows. See for information on how to
+ adjust those parameters, if necessary.
+
relevant for
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 QNX> and
-
BeOS> ports, PostgreSQL>
- provides its own replacement implementation of these facilities.)
+ with BSD heritage. (For the Windows>,
+ QNX> and BeOS>
+ ports,
PostgreSQL> provides its own replacement
+ implementation of these facilities.)
|
SHMMAX>>
Maximum size of shared memory segment (bytes)>
- 250 kB + 8.2 kB * +
- 14.2 kB * up to infinity
+ at least several megabytes (see text)
|
bytes, of a shared memory segment. If you get an error message from
shmget> like 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 (
- (
- (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
- 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
+
PostgreSQL> configuration parameters, as shown in
+ .
+ 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
+
PostgreSQL> to run with SHMMAX> as small as
+ 1 MB, you need at least 4 MB for acceptable performance, and desirable
+ settings are in the tens of megabytes.
Less likely to cause problems is the minimum size for shared
memory segments (SHMMIN>), which should be at most
- approximately
256 kB for
PostgreSQL> (it is
+ approximately
500 kB for
PostgreSQL> (it is
usually just 1). The maximum number of segments system-wide
(SHMMNI>) or per-process (SHMSEG>) are unlikely
to cause a problem unless your system has them set to zero.
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 magic
+ (<xref linkend="guc-max-connections">), in sets of 16. Each such set will
+ also contain a 17th semaphore which contains a magic
number, to detect collision with semaphore sets used by
other applications. The maximum number of semaphores in the system
is set by SEMMNS>, which consequently must be at least
+
+
+
+
+
Configuration parameters affecting
+
PostgreSQL's shared memory usage>
+
+
+
+ |
+ Name>
+ Approximate multiplier (bytes per increment)>
+
+
+
+
+ |
+ >
+ 400 (but see also max_locks_per_transaction>)
+
+
+ |
+ >
+ 600 (but see also max_locks_per_transaction>)
+
+
+ |
+ >
+ 220 * ( +
+ )>
+
+
+ |
+ >
+ 8300>
+
+
+ |
+ >
+ 8200>
+
+
+ |
+ >
+ 70>
+
+
+ |
+ >
+ 6>
+
+
+
+
#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.
#---------------------------------------------------------------------------