+ linkend="client-authentication">).
+ By default, all three configuration files are stored
+ in the database cluster's data directory. The options described
+ in this subsection allow the configuration files to be placed elsewhere.
+ (Doing so can ease administration. In particular it is often
+ easier to ensure that the configuration files are properly backed-up
+ when they are kept separate.)
+
+
data_directory (string)
- Specifies the configuration file for host-based authentication.
+ Specifies the configuration file for host-based authentication
+ (customarily called pg_hba.conf>).
This option can only be set at server start.
Specifies the configuration file for
+ (customarily called pg_ident.conf>).
This option can only be set at server start.
- Specifies that the
postmaster> should create an
- additional process-id (PID) file for use by server administration
- programs.
- This option can only be set at server start.
+ Specifies the name of an additional process-id (PID) file that the
+
postmaster> should create for use by server
+ administration programs.
+ This option can only be set at server start.
- In a default installation, none of the above options is set explicitly
- in the postgresql.conf file. Instead, the
+ In a default installation, none of the above options are set explicitly.
+ Instead, the
data directory is specified by the command-line
option or the PGDATA environment variable, and the
- configuration files are all placed within the data directory.
+ configuration files are all found within the data directory.
- It is also possible to separate the configuration files from the data
- directory, which can ease administration. (In particular it is often
- easier to ensure that the configuration files are properly backed-up
- when they are kept separate.) To do this, the
+ If you wish to keep the configuration files elsewhere than the
+ data directory, the postmaster's
command-line option or PGDATA environment variable
must point to the directory containing the configuration files,
- and the data_directory> option is set in
+ and the data_directory> option must be set in
postgresql.conf (or on the command line) to show
where the data directory is actually located. Notice that
- data_directory> overrides for the location
+ data_directory> overrides and
+ PGDATA for the location
of the data directory, but not for the location of the configuration
files.
- Determines the number of connection
slots that
+ Determines the number of connection
slots that
are reserved for connections by
PostgreSQL>
superusers. At most
connections can ever be active simultaneously. Whenever the
- Sets the access permissions of the Unix-domain socket. Unix
- domain sockets use the usual Unix file system permission set.
+ Sets the access permissions of the Unix-domain socket. Unix-domain
+ sockets use the usual Unix file system permission set.
The option value is expected to be a numeric mode
specification in the form accepted by the
chmod and umask
anyone can connect. Reasonable alternatives are
0770 (only user and group, see also
unix_socket_group) and 0700
- (only user). (Note that actually for a Unix domain socket, only write
- permission matters and there is no point in setting or revoking
+ (only user). (Note that for a Unix-domain socket, only write
+ permission matters and so there is no point in setting or revoking
read or execute permissions.)
Specifies the
Rendezvous broadcast
name. By default, the computer name is used, specified as an
- empty string ''. This option is only meaningful on platforms
-
that support Rendezvous. This
+ empty string ''. This option is ignored if the server was not
+
compiled with Rendezvous support. This
option can only be set at server start.
- If mylib> or mylib_init> are not found, the
- server will fail to start.
+ If a specified library or initialization function is not found,
+ the server will fail to start.
By preloading a shared library (and initializing it if
applicable), the library startup time is avoided when the
library is first used. However, the time to start each new
- server process may increase, even if that process never
- uses the library.
+ server process may increase slightly, even if that process never
+ uses the library. So this option is recommended only for
+ libraries that will be used in most sessions.
- Write a message to the server logs if checkpoints caused by
+ Write a message to the server log if checkpoints caused by
the filling of checkpoint segment files happen closer together
than this many seconds. The default is 30 seconds.
Zero turns off the warning.
file.
- It is important for the command to return a zero exit status only if
- it succeeds. Examples:
+ It is important for the command to return a zero exit status if
+ and only if it succeeds. Examples:
archive_command = 'cp "%p" /mnt/server/archivedir/"%f"'
archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows
Planner Method Configuration
- These configuration parameters provide a crude method for
+ These configuration parameters provide a crude method of
influencing the query plans chosen by the query optimizer. If
the default plan chosen by the optimizer for a particular query
is not optimal, a temporary solution may be found by using one
of these configuration parameters to force the optimizer to
- choose a better plan. Other ways to improve the quality of the
- plans chosen by the optimizer include configuring the
+ choose a different plan. Turning one of these settings off
+ permanently is seldom a good idea, however.
+ Better ways to improve the quality of the
+ plans chosen by the optimizer include adjusting the
linkend="runtime-config-query-constants"
endterm="runtime-config-query-constants-title">, running
linkend="sql-analyze" endterm="sql-analyze-title"> more
frequently, increasing the value of the
linkend="guc-default-statistics-target"> configuration parameter,
- and increasing the amount of statistics collected for a
- particular column using ALTER TABLE SET
+ and increasing the amount of statistics collected for
+ specific columns using ALTER TABLE SET
STATISTICS.
Enables or disables the query planner's use of hashed
- aggregation plan types. The default is on. This is used for
- debugging the query planner.
+ aggregation plan types. The default is on.
Enables or disables the query planner's use of hash-join plan
- types. The default is on. This is used for debugging the query
- planner.
+ types. The default is on.
Enables or disables the query planner's use of index-scan plan
- types. The default is on. This is used for debugging the query
- planner.
+ types. The default is on.
Enables or disables the query planner's use of merge-join plan
- types. The default is on. This is used for debugging the query
- planner.
+ types. The default is on.
plans. It's not possible to suppress nested-loop joins entirely,
but turning this variable off discourages the planner from using
one if there are other methods available. The default is
- on. This is used for debugging the query planner.
+ on.
plan types. It's not possible to suppress sequential scans
entirely, but turning this variable off discourages the planner
from using one if there are other methods available. The
- default is on. This is used for debugging the query planner.
+ default is on.
steps. It's not possible to suppress explicit sorts entirely,
but turning this variable off discourages the planner from
using one if there are other methods available. The default
- is on. This is used for debugging the query planner.
+ is on.
Enables or disables the query planner's use of
TID>
- scan plan types. The default is on. This is used for debugging
- the query planner.
+ scan plan types. The default is on.
message that is logged. Valid values are TERSE>,
DEFAULT>, and VERBOSE>, each adding more
fields to displayed messages.
+ Only superusers can change this setting.
ERROR
- Reports an error that caused the current transaction to abort.
+ Reports an error that caused the current command to abort.
- These options enable various debugging output to be sent to
- the client or server log. For each executed query, they print
+ These options enable various debugging output to be emitted.
+ For each executed query, they print
the resulting parse tree, the query rewriter output, or the
execution plan. debug_pretty_print indents
these displays to produce a more readable but much longer
output format. client_min_messages or
log_min_messages must be
- DEBUG1 or lower to send the output to the
- client or server logs. These options are off by default.
+ DEBUG1 or lower to actually send this output
+ to the client or the server log, respectively.
+ These options are off by default.
- This outputs a line to the server logs detailing each successful
+ This outputs a line to the server log detailing each successful
connection. This is off by default, although it is probably very
useful. This option can only be set at server start or in the
postgresql.conf configuration file.
- This outputs a line in the server logs similar to
+ This outputs a line in the server log similar to
log_connections but at session termination,
and includes the duration of the session. This is off by
default. This option can only be set at server start or in the
- By default, connection logs only show the IP address of the
- connecting host. If you want it to show the host name you can
- turn this on, but depending on your host name resolution setup
- it might impose a non-negligible performance penalty. This
- option can only be set at server start.
+ By default, connection log messages only show the IP address of the
+ connecting host. Turning on this option causes logging of the
+ host name as well. Note that depending on your host name resolution
+ setup this might impose a non-negligible performance penalty. This
+ option can only be set at server start or in the
+ postgresql.conf file.
This parameter is normally true. When set to false, it disables
- validation of the function body string
in
+ validation of the function body string
during
linkend="sql-createfunction"
endterm="sql-createfunction-title">. Disabling validation is
occasionally useful to avoid problems such as forward
- Aborts any statement that takes over the specified number of
+ Abort any statement that takes over the specified number of
milliseconds. A value of zero (the default) turns off the limitation.
The shared lock table is sized on the assumption that at most
max_locks_per_transaction *
max_connections distinct objects will need to
- be locked at any one time. The default, 64, has historically
+ 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.)
+ The default, 64, has historically
proven sufficient, but you might need to raise this value if you
have clients that touch many different tables in a single
transaction. This option can only be set at server start.
advanced>, extended>, or basic>.
The default is advanced>. The extended>
setting may be useful for exact backwards compatibility with
- pre-7.4 releases of
PostgreSQL>.
+ pre-7.4 releases of
PostgreSQL>. See
+ for details.
This controls whether CREATE TABLE and
- CREATE TABLE AS will include OIDs in
+ CREATE TABLE AS include an OID column in
newly-created tables, if neither WITH OIDS
nor WITHOUT OIDS is specified. It also
determines whether OIDs will be included in tables created by
The following parameters> are read-only, and are determined
when
PostgreSQL is compiled or when it is
installed. As such, they have been excluded from the sample
- postgresql.conf> file. These options determine
+ postgresql.conf> file. These options report
various aspects of
PostgreSQL behavior
that may be of interest to certain applications, particularly
administrative front-ends.
Detection of a damaged page header normally causes
PostgreSQL> to report an error, aborting the current
- transaction. Setting zero_damaged_pages> to true causes
+ command. Setting zero_damaged_pages> to true causes
the system to instead report a warning, zero out the damaged page,
and continue processing. This behavior will destroy data>,
namely all the rows on the damaged page. But it allows you to get
|
SEMVMX>>
Maximum value of semaphore>
- at least 1000 (The default is often 32767, don't change unless asked to.)>
+ at least 1000 (The default is often 32767, don't change unless forced to)>
shared memory parameter is SHMMAX>, the maximum size, in
bytes, of a shared memory segment. If you get an error message from
shmget> like Invalid argument>, it is
- possible that this limit has been exceeded. The size of the required
+ 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 by multiplying the number of buffers and the
- block size (8 kB by default) plus ample overhead (at least half a
- megabyte). Any error message you might get will contain the size of
- the failed allocation request.
+ required segment size as suggested in
+ linkend="sysvipc-parameters">. Any error message you might get will
+ contain the size of the failed allocation request.
+
+
+ Some systems also have a limit on the total amount of shared memory in
+ the system (SHMALL>). Make sure this is large enough
+ for
PostgreSQL> plus any other applications that
+ are using shared memory segments. (Caution: SHMALL>
+ is measured in pages rather than bytes on many systems.)
memory segments (SHMMIN>), which should be at most
approximately 256 kB for
PostgreSQL> (it is
usually just 1). The maximum number of segments system-wide
- (SHMMNI>) or per-process (SHMSEG>) should
- not cause a problem unless your system has them set to zero. Some
- systems also have a limit on the total amount of shared memory in
- the system; see the platform-specific instructions below.
+ (SHMMNI>) or per-process (SHMSEG>) are unlikely
+ to cause a problem unless your system has them set to zero.
By default, only 4 MB of shared memory is supported. Keep in
mind that shared memory is not pageable; it is locked in RAM.
To increase the amount of shared memory supported by your
- system, add the following to your kernel configuration
- file. A SHMALL> value of 1024 represents 4 MB of
- shared memory. The following increases the maximum shared
- memory area to 32 MB:
+ system, add something like the following to your kernel configuration
+ file:
options "SHMALL=8192"
options "SHMMAX=\(SHMALL*PAGE_SIZE\)"
- For those running 4.3 or later, you will probably need to increase
+ SHMALL> is measured in 4KB pages, so a value of
+ 1024 represents 4 MB of shared memory. Therefore the above increases
+ the maximum shared memory area to 32 MB.
+ For those running 4.3 or later, you will probably also need to increase
KERNEL_VIRTUAL_MB> above the default 248>.
Once all changes have been made, recompile the kernel, and reboot.
Semaphores>
- You may need to increase the number of semaphores. By
- default,
PostgreSQL> allocates 34 semaphores,
- which is over half the default system total of 60. Set the
+ You will probably want to increase the number of semaphores
+ as well; the default system total of 60 will only allow about
+
50 PostgreSQL connections. Set the
values you want in your kernel configuration file, e.g.:
options "SEMMNI=40"
sysctl -w kern.sysv.shmall
In OS X 10.3, these commands have been moved to /etc/rc>
- and must be edited there. Note that /etc/rc> is usually
+ and must be edited there. You'll need to reboot to make changes
+ take effect. Note that /etc/rc> is usually
overwritten by OS X updates (such as 10.3.6 to 10.3.7) so you
should expect to have to redo your editing after each update.
+ SHMALL> is measured in 4KB pages on this platform.
+
This is the Immediate Shutdown, which
will cause the postmaster process to send a
SIGQUIT to all child processes and exit
- immediately (without properly shutting itself down). The child processes
+ immediately, without properly shutting itself down. The child processes
likewise exit immediately upon receiving
SIGQUIT. This will lead to recovery (by
replaying the WAL log) upon next start-up. This is recommended
-
- It is best not to use SIGKILL to shut down
- the server. This will prevent the server from releasing
- shared memory and semaphores, which may then have to be done by
- manually.
-
-
+ The program provides a convenient
+ interface for sending these signals to shut down the server.
+
- The
PID> of the postmaster process can be found using the
- ps program, or from the file
- postmaster.pid in the data directory. So for
+ Alternatively, you can send the signal directly using kill>.
+ The
PID> of the postmaster process can be
+ found using the ps program, or from the file
+ postmaster.pid in the data directory. For
example, to do a fast shutdown:
$ kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`
- The program pg_ctl is a shell script
- that provides a more convenient interface for shutting down the
- server.
-
+
+
+ It is best not to use SIGKILL to shut down
+ the server. Doing so will prevent the server from releasing
+ shared memory and semaphores, which may then have to be done
+ manually before a new server can be started. Furthermore,
+ SIGKILL kills the postmaster
+ process without letting it relay the signal to its subprocesses,
+ so it will be necessary to kill the individual subprocesses by hand as
+ well.
+
+
With
SSL> support compiled in, the
PostgreSQL> server can be started with
SSL> enabled by setting the parameter
- to on in postgresql.conf>. When
+ to on> in
+ postgresql.conf>. When
starting in
SSL> mode, the server will look for the
files server.key> and server.crt> in the
- data directory, which should contain the server private key
+ data directory, which must contain the server private key
and certificate, respectively. These files must be set up correctly
before an
SSL>-enabled server can start. If the private key is
protected with a passphrase, the server will prompt for the
The server will listen for both standard and
SSL>
connections on the same TCP port, and will negotiate with any
- connecting client on whether to use
SSL>. See
+ connecting client on whether to use
SSL>. By default,
+ this is at the client's option; see
linkend="auth-pg-hba-conf"> about how to set up the server to
require use of
SSL> for some or all connections.
For details on how to create your server private key and certificate,
- refer to the
OpenSSL> documentation. A simple
- self-signed certificate can be used to get started for testing, but a
- certificate signed by a certificate authority (
CA>) (either one of the global
+ refer to the
OpenSSL> documentation. A
+ self-signed certificate can be used for testing, but a
+ certificate signed by a certificate authority (
CA>)
+ (either one of the global
CAs> or a local one) should be used in production so the
client can verify the server's identity. To create a quick
self-signed certificate, use the following
One can use
SSH to encrypt the network
connection between clients and a
PostgreSQL server. Done properly, this
- provides an adequately secure network connection.
+ provides an adequately secure network connection, even for non-SSL-capable
+ clients.
The first number in the argument, 3333, is the
port number of your end of the tunnel; it can be chosen freely. The
second number, 5432, is the remote end of the tunnel: the port
- number your server is using. The name or the address in between
+ number your server is using. The name or IP address between
the port numbers is the host with the database server you are going
to connect to. In order to connect to the database server using
this tunnel, you connect to port 3333 on the local machine:
To the database server it will then look as though you are really
user joe@foo.com and it will use whatever
- authentication procedure was set up for this user. In order for the
+ authentication procedure was configured for connections from this
+ user and host. Note that the server will not think the connection is
+ SSL-encrypted, since in fact it is not encrypted between the
+
PostgreSQL server. This should not pose any
+ extra security risk as long as they are on the same machine.
+
+ In order for the
tunnel setup to succeed you must be allowed to connect via
ssh as joe@foo.com, just
as if you had attempted to use ssh to set up a