config.sgml 211 KB
Newer Older
1
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.146 2007/09/24 03:12:23 tgl Exp $ -->
2

3
<chapter Id="runtime-config">
4
  <title>Server Configuration</title>
5 6 7 8 9 10 11 12 13

  <indexterm>
   <primary>configuration</primary>
   <secondary>of the server</secondary>
  </indexterm>

  <para>
   There are many configuration parameters that affect the behavior of
   the database system. In the first section of this chapter, we
14
   describe how to set configuration parameters. The subsequent sections
15 16 17 18 19 20 21 22
   discuss each parameter in detail.
  </para>

  <sect1 id="config-setting">
   <title>Setting Parameters</title>

   <para>
    All parameter names are case-insensitive. Every parameter takes a
23
    value of one of four types: Boolean, integer, floating point,
24
    or string. Boolean values can be written as <literal>ON</literal>,
25 26 27 28 29 30
    <literal>OFF</literal>, <literal>TRUE</literal>,
    <literal>FALSE</literal>, <literal>YES</literal>,
    <literal>NO</literal>, <literal>1</literal>, <literal>0</literal>
    (all case-insensitive) or any unambiguous prefix of these.
   </para>

31
   <para>
32 33 34 35 36 37 38 39 40 41 42
    Some settings specify a memory or time value.  Each of these has an
    implicit unit, which is either kilobytes, blocks (typically eight
    kilobytes), milliseconds, seconds, or minutes.  Default units can be
    queried by referencing <literal>pg_settings.unit</>. For convenience,
    a different unit can also be specified explicitly.  Valid memory units
    are <literal>kB</literal> (kilobytes), <literal>MB</literal>
    (megabytes), and <literal>GB</literal> (gigabytes); valid time units
    are <literal>ms</literal> (milliseconds), <literal>s</literal>
    (seconds), <literal>min</literal> (minutes), <literal>h</literal>
    (hours), and <literal>d</literal> (days).  Note that the multiplier
    for memory units is 1024, not 1000.
43 44
   </para>

45 46 47
   <para>
    One way to set these parameters is to edit the file
    <filename>postgresql.conf</><indexterm><primary>postgresql.conf</></>,
48
    which is normally kept in the data directory. (<application>initdb</>
49 50 51 52 53 54
    installs a default copy there.) An example of what this file might look
    like is:
<programlisting>
# This is a comment
log_connections = yes
log_destination = 'syslog'
55
search_path = '"$user", public'
56
shared_buffers = 128MB
57 58 59 60 61
</programlisting>
    One parameter is specified per line. The equal sign between name and
    value is optional. Whitespace is insignificant and blank lines are
    ignored. Hash marks (<literal>#</literal>) introduce comments
    anywhere.  Parameter values that are not simple identifiers or
62 63
    numbers must be single-quoted.  To embed a single quote in a parameter
    value, write either two quotes (preferred) or backslash-quote.
64 65 66 67 68 69 70 71 72 73
   </para>

   <para>
    <indexterm>
     <primary><literal>include</></primary>
     <secondary>in configuration file</secondary>
    </indexterm>
    In addition to parameter settings, the <filename>postgresql.conf</>
    file can contain <firstterm>include directives</>, which specify
    another file to read and process as if it were inserted into the
74
    configuration file at this point.  Include directives simply look like:
75 76 77
<programlisting>
include 'filename'
</programlisting>
Peter Eisentraut's avatar
Peter Eisentraut committed
78
    If the file name is not an absolute path, it is taken as relative to
79 80 81
    the directory containing the referencing configuration file.
    Inclusions can be nested.
   </para>
82 83 84 85 86

   <para>
    <indexterm>
     <primary>SIGHUP</primary>
    </indexterm>
87
    The configuration file is reread whenever the main server process receives a
88
    <systemitem>SIGHUP</> signal (which is most easily sent by means
89
    of <literal>pg_ctl reload</>). The main server process
90 91 92 93 94 95 96 97 98 99
    also propagates this signal to all currently running server
    processes so that existing sessions also get the new
    value. Alternatively, you can send the signal to a single server
    process directly.  Some parameters can only be set at server start;
    any changes to their entries in the configuration file will be ignored
    until the server is restarted.
   </para>

   <para>
    A second way to set these configuration parameters is to give them
100
    as a command-line option to the <command>postgres</command> command, such as:
101
<programlisting>
102
postgres -c log_connections=yes -c log_destination='syslog'
103 104 105 106 107
</programlisting>
    Command-line options override any conflicting settings in
    <filename>postgresql.conf</filename>.  Note that this means you won't
    be able to change the value on-the-fly by editing
    <filename>postgresql.conf</filename>, so while the command-line
108
    method might be convenient, it can cost you flexibility later.
109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125
   </para>

   <para>
    Occasionally it is useful to give a command line option to
    one particular session only. The environment variable
    <envar>PGOPTIONS</envar> can be used for this purpose on the
    client side:
<programlisting>
env PGOPTIONS='-c geqo=off' psql
</programlisting>
    (This works for any <application>libpq</>-based client application, not
    just <application>psql</application>.) Note that this won't work for
    parameters that are fixed when the server is started or that must be
    specified in <filename>postgresql.conf</filename>.
   </para>

   <para>
126
    Furthermore, it is possible to assign a set of parameter settings to
127 128 129 130 131 132
    a user or a database.  Whenever a session is started, the default
    settings for the user and database involved are loaded.  The
    commands <xref linkend="sql-alteruser" endterm="sql-alteruser-title">
    and <xref linkend="sql-alterdatabase" endterm="sql-alterdatabase-title">,
    respectively, are used to configure these settings.  Per-database
    settings override anything received from the
133
    <command>postgres</command> command-line or the configuration
134
    file, and in turn are overridden by per-user settings; both are
135
    overridden by per-session settings.
136 137 138 139 140 141 142 143 144 145 146 147
   </para>

   <para>
    Some parameters can be changed in individual <acronym>SQL</acronym>
    sessions with the <xref linkend="SQL-SET" endterm="SQL-SET-title">
    command, for example:
<screen>
SET ENABLE_SEQSCAN TO OFF;
</screen>
    If <command>SET</> is allowed, it overrides all other sources of
    values for the parameter. Some parameters cannot be changed via
    <command>SET</command>: for example, if they control behavior that
148 149
    cannot be changed without restarting the entire
    <productname>PostgreSQL</productname> server.  Also, some parameters can
150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178
    be modified via <command>SET</command> or <command>ALTER</> by superusers,
    but not by ordinary users.
   </para>

   <para>
    The <xref linkend="SQL-SHOW" endterm="SQL-SHOW-title">
    command allows inspection of the current values of all parameters.
   </para>

   <para>
    The virtual table <structname>pg_settings</structname>
    (described in <xref linkend="view-pg-settings">) also allows
    displaying and updating session run-time parameters.  It is equivalent
    to <command>SHOW</> and <command>SET</>, but can be more convenient
    to use because it can be joined with other tables, or selected from using
    any desired selection condition.
   </para>
  </sect1>

   <sect1 id="runtime-config-file-locations">
    <title>File Locations</title>

     <para>
      In addition to the <filename>postgresql.conf</filename> file
      already mentioned, <productname>PostgreSQL</productname> uses
      two other manually-edited configuration files, which control
      client authentication (their use is discussed in <xref
      linkend="client-authentication">).  By default, all three
      configuration files are stored in the database cluster's data
179
      directory.  The parameters described in this section allow the
180 181 182 183 184 185 186 187 188 189 190 191 192 193 194
      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.)
     </para>

     <variablelist>
     <varlistentry id="guc-data-directory" xreflabel="data_directory">
      <term><varname>data_directory</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>data_directory</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
         Specifies the directory to use for data storage.
195
         This parameter can only be set at server start.
196 197 198 199 200 201 202 203 204 205 206 207 208
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-config-file" xreflabel="config_file">
      <term><varname>config_file</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>config_file</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
         Specifies the main server configuration file
         (customarily called <filename>postgresql.conf</>).
Peter Eisentraut's avatar
Peter Eisentraut committed
209
         This parameter can only be set on the <command>postgres</command> command line.
210 211 212 213 214 215 216 217 218 219 220 221 222
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-hba-file" xreflabel="hba_file">
      <term><varname>hba_file</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>hba_file</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
         Specifies the configuration file for host-based authentication
         (customarily called <filename>pg_hba.conf</>).
223
         This parameter can only be set at server start.
224 225 226 227 228 229 230 231 232 233 234 235 236 237
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-ident-file" xreflabel="ident_file">
      <term><varname>ident_file</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>ident_file</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
         Specifies the configuration file for
         <application>ident</> authentication
         (customarily called <filename>pg_ident.conf</>).
238
         This parameter can only be set at server start.
239 240 241 242 243 244 245 246 247 248 249 250
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-external-pid-file" xreflabel="external_pid_file">
      <term><varname>external_pid_file</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>external_pid_file</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the name of an additional process-id (PID) file that the
251
        server should create for use by server administration programs.
252
        This parameter can only be set at server start.
253 254 255 256 257 258
       </para>
      </listitem>
     </varlistentry>
     </variablelist>

     <para>
259 260
      In a default installation, none of the above parameters are set
      explicitly.  Instead, the
261 262 263 264 265 266 267
      data directory is specified by the <option>-D</option> command-line
      option or the <envar>PGDATA</envar> environment variable, and the
      configuration files are all found within the data directory.
     </para>

     <para>
      If you wish to keep the configuration files elsewhere than the
Peter Eisentraut's avatar
Peter Eisentraut committed
268
      data directory, the <command>postgres</command> <option>-D</option>
269 270
      command-line option or <envar>PGDATA</envar> environment variable
      must point to the directory containing the configuration files,
271
      and the <varname>data_directory</> parameter must be set in
272 273 274 275 276 277 278 279 280 281
      <filename>postgresql.conf</filename> (or on the command line) to show
      where the data directory is actually located.  Notice that
      <varname>data_directory</> overrides <option>-D</option> and
      <envar>PGDATA</envar> for the location
      of the data directory, but not for the location of the configuration
      files.
     </para>

     <para>
      If you wish, you can specify the configuration file names and locations
282
      individually using the parameters <varname>config_file</>,
283
      <varname>hba_file</> and/or <varname>ident_file</>.
284
      <varname>config_file</> can only be specified on the
285
      <command>postgres</command> command line, but the others can be
286
      set within the main configuration file.  If all three parameters plus
287 288 289 290 291
      <varname>data_directory</> are explicitly set, then it is not necessary
      to specify <option>-D</option> or <envar>PGDATA</envar>.
     </para>

     <para>
292
      When setting any of these parameters, a relative path will be interpreted
293
      with respect to the directory in which <command>postgres</command>
294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313
      is started.
     </para>
   </sect1>

   <sect1 id="runtime-config-connection">
    <title>Connections and Authentication</title>

    <sect2 id="runtime-config-connection-settings">
     <title>Connection Settings</title>

     <variablelist>

     <varlistentry id="guc-listen-addresses" xreflabel="listen_addresses">
      <term><varname>listen_addresses</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>listen_addresses</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
         Specifies the TCP/IP address(es) on which the server is
314
         to listen for connections from client applications.
315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349
         The value takes the form of a comma-separated list of host names
         and/or numeric IP addresses.  The special entry <literal>*</>
         corresponds to all available IP interfaces.
         If the list is empty, the server does not listen on any IP interface
         at all, in which case only Unix-domain sockets can be used to connect
         to it.
         The default value is <systemitem class="systemname">localhost</>,
         which allows only local <quote>loopback</> connections to be made.
         This parameter can only be set at server start.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-port" xreflabel="port">
      <term><varname>port</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>port</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        The TCP port the server listens on; 5432 by default.  Note that the
        same port number is used for all IP addresses the server listens on.
        This parameter can only be set at server start.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-max-connections" xreflabel="max_connections">
      <term><varname>max_connections</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>max_connections</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Determines the maximum number of concurrent connections to the
350
        database server. The default is typically 100 connections, but
351
        might be less if your kernel settings will not support it (as
352 353
        determined during <application>initdb</>).  This parameter can
        only be set at server start.
354 355 356
       </para>

       <para>
357
        Increasing this parameter might cause <productname>PostgreSQL</>
358 359 360 361 362 363 364
        to request more <systemitem class="osname">System V</> shared
        memory or semaphores 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>
365

366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385
     <varlistentry id="guc-superuser-reserved-connections"
     xreflabel="superuser_reserved_connections">
      <term><varname>superuser_reserved_connections</varname>
      (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>superuser_reserved_connections</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Determines the number of connection <quote>slots</quote> that
        are reserved for connections by <productname>PostgreSQL</>
        superusers.  At most <xref linkend="guc-max-connections">
        connections can ever be active simultaneously.  Whenever the
        number of active concurrent connections is at least
        <varname>max_connections</> minus
        <varname>superuser_reserved_connections</varname>, new
        connections will be accepted only for superusers.
       </para>

       <para>
386 387 388
        The default value is three connections. The value must be less
        than the value of <varname>max_connections</varname>. This
        parameter can only be set at server start.
389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-unix-socket-directory" xreflabel="unix_socket_directory">
      <term><varname>unix_socket_directory</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>unix_socket_directory</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the directory of the Unix-domain socket on which the
        server is to listen for
        connections from client applications.  The default is normally
        <filename>/tmp</filename>, but can be changed at build time.
        This parameter can only be set at server start.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-unix-socket-group" xreflabel="unix_socket_group">
      <term><varname>unix_socket_group</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>unix_socket_group</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the owning group of the Unix-domain socket.  (The owning
        user of the socket is always the user that starts the
418
        server.)  In combination with the parameter
419 420
        <varname>unix_socket_permissions</varname> this can be used as
        an additional access control mechanism for Unix-domain connections.
421 422
        By default this is the empty string, which selects the default
        group for the current user.  This parameter can only be set at
423 424 425 426 427 428 429 430 431 432 433 434 435 436
        server start.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-unix-socket-permissions" xreflabel="unix_socket_permissions">
      <term><varname>unix_socket_permissions</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>unix_socket_permissions</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the access permissions of the Unix-domain socket.  Unix-domain
        sockets use the usual Unix file system permission set.
437
        The parameter value is expected to be a numeric mode
438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459
        specification in the form accepted by the
        <function>chmod</function> and <function>umask</function>
        system calls.  (To use the customary octal format the number
        must start with a <literal>0</literal> (zero).)
       </para>

       <para>
        The default permissions are <literal>0777</literal>, meaning
        anyone can connect. Reasonable alternatives are
        <literal>0770</literal> (only user and group, see also
        <varname>unix_socket_group</varname>) and <literal>0700</literal>
        (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.)
       </para>

       <para>
        This access control mechanism is independent of the one
        described in <xref linkend="client-authentication">.
       </para>

       <para>
460
        This parameter can only be set at server start.
461 462 463
       </para>
      </listitem>
     </varlistentry>
464

465 466 467 468 469 470 471 472
     <varlistentry id="guc-bonjour-name" xreflabel="bonjour_name">
      <term><varname>bonjour_name</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>bonjour_name</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the <productname>Bonjour</productname> broadcast
473 474 475 476 477
        name.  The computer name is used if this parameter is set to the
        empty string <literal>''</> (which is the default).  This parameter is
        ignored if the server was not compiled with
        <productname>Bonjour</productname> support.
        This parameter can only be set at server start.
478 479 480
       </para>
      </listitem>
     </varlistentry>
481

482 483 484 485 486 487 488
     <varlistentry id="guc-tcp-keepalives-idle" xreflabel="tcp_keepalives_idle">
      <term><varname>tcp_keepalives_idle</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>tcp_keepalives_idle</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
489
        On systems that support the <symbol>TCP_KEEPIDLE</symbol> socket option, specifies the
490
        number of seconds between sending keepalives on an otherwise idle
491 492
        connection. A value of zero uses the system default. If <symbol>TCP_KEEPIDLE</symbol> is
        not supported, this parameter must be zero. This parameter is ignored for
493 494 495 496
        connections made via a Unix-domain socket.
       </para>
      </listitem>
     </varlistentry>
497

498 499 500 501 502 503 504
     <varlistentry id="guc-tcp-keepalives-interval" xreflabel="tcp_keepalives_interval">
      <term><varname>tcp_keepalives_interval</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>tcp_keepalives_interval</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
505
        On systems that support the <symbol>TCP_KEEPINTVL</symbol> socket option, specifies how
506
        long, in seconds, to wait for a response to a keepalive before
507 508
        retransmitting. A value of zero uses the system default. If <symbol>TCP_KEEPINTVL</symbol>
        is not supported, this parameter must be zero. This parameter is ignored
509 510 511 512
        for connections made via a Unix-domain socket.
       </para>
      </listitem>
     </varlistentry>
513

514 515 516 517 518 519 520
     <varlistentry id="guc-tcp-keepalives-count" xreflabel="tcp_keepalives_count">
      <term><varname>tcp_keepalives_count</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>tcp_keepalives_count</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
521
        On systems that support the <symbol>TCP_KEEPCNT</symbol> socket option, specifies how
522
        many keepalives can be lost before the connection is considered dead.
523 524
        A value of zero uses the system default. If <symbol>TCP_KEEPCNT</symbol> is not
        supported, this parameter must be zero. This parameter is ignored
525
        for connections made via a Unix-domain socket.
526 527 528
       </para>
      </listitem>
     </varlistentry>
529

530 531 532 533
     </variablelist>
     </sect2>
     <sect2 id="runtime-config-connection-security">
     <title>Security and Authentication</title>
534

535 536 537 538 539 540 541 542 543 544 545 546 547 548
     <variablelist>
     <varlistentry id="guc-authentication-timeout" xreflabel="authentication_timeout">
      <term><varname>authentication_timeout</varname> (<type>integer</type>)</term>
      <indexterm><primary>timeout</><secondary>client authentication</></indexterm>
      <indexterm><primary>client authentication</><secondary>timeout during</></indexterm>
      <indexterm>
       <primary><varname>authentication_timeout</> configuration parameter</primary>
      </indexterm>

      <listitem>
       <para>
        Maximum time to complete client authentication, in seconds. If a
        would-be client has not completed the authentication protocol in
        this much time, the server breaks the connection. This prevents
549
        hung clients from occupying a connection indefinitely.
550
        The default is one minute (<literal>1m</>).
551 552
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571
       </para>
      </listitem>
     </varlistentry>
     
     <varlistentry id="guc-ssl" xreflabel="ssl">
      <term><varname>ssl</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>ssl</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Enables <acronym>SSL</> connections. Please read
        <xref linkend="ssl-tcp"> before using this. The default
        is <literal>off</>. This parameter can only be set at server
        start.
       </para>
      </listitem>
     </varlistentry>

572 573
     <varlistentry id="guc-ssl-ciphers" xreflabel="ssl_ciphers">
      <term><varname>ssl_ciphers</varname> (<type>string</type>)</term>
Bruce Momjian's avatar
Bruce Momjian committed
574 575 576 577 578
      <indexterm>
       <primary><varname>ssl_ciphers</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
579 580
        Specifies a list of <acronym>SSL</> ciphers that are allowed to be
        used on secure connections. See the <application>openssl</>
Bruce Momjian's avatar
Bruce Momjian committed
581 582 583 584 585
        manual page for a list of supported ciphers.
       </para>
      </listitem>
     </varlistentry>

586 587 588 589 590 591 592 593 594 595 596
     <varlistentry id="guc-password-encryption" xreflabel="password_encryption">
      <term><varname>password_encryption</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>password_encryption</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        When a password is specified in <xref
        linkend="sql-createuser" endterm="sql-createuser-title"> or
        <xref linkend="sql-alteruser" endterm="sql-alteruser-title">
        without writing either <literal>ENCRYPTED</> or
597
        <literal>UNENCRYPTED</>, this parameter determines whether the
598 599 600 601 602 603 604 605 606 607 608 609 610 611
        password is to be encrypted. The default is <literal>on</>
        (encrypt the password).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-krb-server-keyfile" xreflabel="krb_server_keyfile">
      <term><varname>krb_server_keyfile</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>krb_server_keyfile</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the location of the Kerberos server key file. See
Magnus Hagander's avatar
Magnus Hagander committed
612 613
        <xref linkend="kerberos-auth"> or <xref linkend="gssapi-auth"> 
        for details. This parameter can only be set at server start.
614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-krb-srvname" xreflabel="krb_srvname">
      <term><varname>krb_srvname</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>krb_srvname</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the Kerberos service name. See <xref linkend="kerberos-auth">
        for details.  This parameter can only be set at server start.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-krb-server-hostname" xreflabel="krb_server_hostname">
      <term><varname>krb_server_hostname</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>krb_server_hostname</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
638
        Sets the host name part of the service principal.
639
        This, combined with <varname>krb_srvname</>, is used to generate
640 641
        the complete service principal, that is
        <varname>krb_srvname</><literal>/</><varname>krb_server_hostname</><literal>@</>REALM.
642
        If not set, the default is the server host name.  See <xref linkend="kerberos-auth">
643
        for details.  This parameter can only be set at server start.
644 645 646 647 648 649 650 651 652 653 654
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-krb-caseins-users" xreflabel="krb_caseins_users">
      <term><varname>krb_caseins_users</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>krb_caseins_users</varname> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
Magnus Hagander's avatar
Magnus Hagander committed
655 656
        Sets whether Kerberos and GSSAPI user names should be treated
        case-insensitively.
657 658 659 660 661 662 663 664 665 666 667 668 669
        The default is <literal>off</> (case sensitive). This parameter
        can only be set at server start.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-db-user-namespace" xreflabel="db_user_namespace">
      <term><varname>db_user_namespace</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>db_user_namespace</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
670 671 672
        This parameter enables per-database user names.  It is off by default.
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
673 674 675 676 677 678 679 680 681 682 683 684 685
       </para>

       <para>
        If this is on, you should create users as <literal>username@dbname</>.
        When <literal>username</> is passed by a connecting client,
        <literal>@</> and the database name are appended to the user
        name and that database-specific user name is looked up by the
        server. Note that when you create users with names containing
        <literal>@</> within the SQL environment, you will need to
        quote the user name.
       </para>

       <para>
686
        With this parameter enabled, you can still create ordinary global
687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719
        users.  Simply append <literal>@</> when specifying the user
        name in the client.  The <literal>@</> will be stripped off
        before the user name is looked up by the server.
       </para>

       <note>
        <para>
         This feature is intended as a temporary measure until a
         complete solution is found.  At that time, this option will
         be removed.
        </para>
       </note>
      </listitem>
     </varlistentry>

    </variablelist>
    </sect2>
   </sect1>

   <sect1 id="runtime-config-resource">
    <title>Resource Consumption</title>

    <sect2 id="runtime-config-resource-memory">
     <title>Memory</title>

     <variablelist>
     <varlistentry id="guc-shared-buffers" xreflabel="shared_buffers">
      <term><varname>shared_buffers</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>shared_buffers</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
720 721
        Sets the amount of memory the database server uses for shared
        memory buffers.  The default is typically 32 megabytes
722
        (<literal>32MB</>), but might be less if your kernel settings will
723 724 725 726 727 728 729 730
        not support it (as determined during <application>initdb</>).
        This setting must be at least 128 kilobytes and at least 16
        kilobytes times <xref linkend="guc-max-connections">.  (Non-default
        values of <symbol>BLCKSZ</symbol> change the minimum.)  However,
        settings significantly higher than the minimum are usually needed
        for good performance.  Several tens of megabytes are recommended
        for production installations.  This parameter can only be set at
        server start.
731 732 733
       </para>

       <para>
734
        Increasing this parameter might cause <productname>PostgreSQL</>
735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750
        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>

     <varlistentry id="guc-temp-buffers" xreflabel="temp_buffers">
      <term><varname>temp_buffers</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>temp_buffers</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the maximum number of temporary buffers used by each database
751 752 753 754 755 756
        session.  These are session-local buffers used only for access to
        temporary tables.  The default is eight megabytes
        (<literal>8MB</>).  The setting can be changed within individual
        sessions, but only up until the first use of temporary tables
        within a session; subsequent attempts to change the value will
        have no effect on that session.
757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783
       </para>

       <para>
        A session will allocate temporary buffers as needed up to the limit
        given by <varname>temp_buffers</>.  The cost of setting a large
        value in sessions that do not actually need a lot of temporary
        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).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-max-prepared-transactions" xreflabel="max_prepared_transactions">
      <term><varname>max_prepared_transactions</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>max_prepared_transactions</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the maximum number of transactions that can be in the
        <quote>prepared</> state simultaneously (see <xref
        linkend="sql-prepare-transaction"
        endterm="sql-prepare-transaction-title">).
        Setting this parameter to zero disables the prepared-transaction
        feature.
784
        The default is five transactions.
785
        This parameter can only be set at server start.
786 787 788 789 790 791 792 793 794 795 796
       </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>
797
        Increasing this parameter might cause <productname>PostgreSQL</>
798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814
        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>

     <varlistentry id="guc-work-mem" xreflabel="work_mem">
      <term><varname>work_mem</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>work_mem</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the amount of memory to be used by internal sort operations
        and hash tables before switching to temporary disk files. The value is
815
        defaults to one megabyte (<literal>1MB</>).
816 817 818 819 820 821 822 823 824 825 826 827 828 829
        Note that for a complex query, several sort or hash operations might be
        running in parallel; each one will be allowed to use as much memory
        as this value specifies before it starts to put data into temporary
        files. Also, several running sessions could be doing such operations
        concurrently.  So the total memory used could be many
        times the value of <varname>work_mem</varname>; it is necessary to
        keep this fact in mind when choosing the value. Sort operations are
        used for <literal>ORDER BY</>, <literal>DISTINCT</>, and
        merge joins.
        Hash tables are used in hash joins, hash-based aggregation, and
        hash-based processing of <literal>IN</> subqueries.
       </para>
      </listitem>
     </varlistentry>
830

831 832 833 834 835 836 837 838 839
     <varlistentry id="guc-maintenance-work-mem" xreflabel="maintenance_work_mem">
      <term><varname>maintenance_work_mem</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>maintenance_work_mem</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the maximum amount of memory to be used in maintenance
        operations, such as <command>VACUUM</command>, <command>CREATE
840 841 842 843 844
        INDEX</>, and <command>ALTER TABLE ADD FOREIGN KEY</>.  It defaults
        to 16 megabytes (<literal>16MB</>).  Since only one of these
        operations can be executed at a time by a database session, and
        an installation normally doesn't have many of them running
        concurrently, it's safe to set this value significantly larger
845
        than <varname>work_mem</varname>.  Larger settings might improve
846
        performance for vacuuming and for restoring database dumps.
847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-max-stack-depth" xreflabel="max_stack_depth">
      <term><varname>max_stack_depth</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>max_stack_depth</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the maximum safe depth of the server's execution stack.
        The ideal setting for this parameter is the actual stack size limit
        enforced by the kernel (as set by <literal>ulimit -s</> or local
        equivalent), less a safety margin of a megabyte or so.  The safety
        margin is needed because the stack depth is not checked in every
        routine in the server, but only in key potentially-recursive routines
864 865
        such as expression evaluation.  The default setting is two
        megabytes (<literal>2MB</>), which is conservatively small and
866
        unlikely to risk crashes.  However, it might be too small to allow
867 868
        execution of complex functions.  Only superusers can change this
        setting.
869
       </para>
870 871 872 873 874 875 876 877 878 879

       <para>
        Setting <varname>max_stack_depth</> higher than
        the actual kernel limit will mean that a runaway recursive function
        can crash an individual backend process.  On platforms where
        <productname>PostgreSQL</productname> can determine the kernel limit,
        it will not let you set this variable to an unsafe value.  However,
        not all platforms provide the information, so caution is recommended
        in selecting a value.
       </para>
880 881 882 883 884 885 886 887 888 889 890 891 892 893 894
      </listitem>
     </varlistentry>

     </variablelist>
     </sect2>
     <sect2 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.
895
      An undersized free space map can cause the database to consume
896 897 898 899
      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.
900
      The last few lines displayed by a database-wide <command>VACUUM VERBOSE</>
901 902 903 904 905 906
      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>
907
      Increasing these parameters might cause <productname>PostgreSQL</>
908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923
      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>
      <indexterm>
       <primary><varname>max_fsm_pages</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the maximum number of disk pages for which free space will
        be tracked in the shared free-space map.  Six bytes of shared memory
924
        are consumed for each page slot.  This setting must be at least
925 926
        16 * <varname>max_fsm_relations</varname>.  The default is chosen
        by <application>initdb</> depending on the amount of available memory,
927
        and can range from 20k to 200k pages.
928
        This parameter can only be set at server start.
929 930 931 932 933 934 935 936 937 938 939 940 941 942
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-max-fsm-relations" xreflabel="max_fsm_relations">
      <term><varname>max_fsm_relations</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>max_fsm_relations</> configuration parameter</primary>
      </indexterm>
      <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
        seventy bytes of shared memory are consumed for each slot.
943
        The default is one thousand relations.
944
        This parameter can only be set at server start.
945 946 947
       </para>
      </listitem>
     </varlistentry>
948

949 950 951 952 953 954 955 956 957 958 959 960 961 962
     </variablelist>
     </sect2>
     <sect2 id="runtime-config-resource-kernel">
     <title>Kernel Resource Usage</title>
     <variablelist>

     <varlistentry id="guc-max-files-per-process" xreflabel="max_files_per_process">
      <term><varname>max_files_per_process</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>max_files_per_process</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the maximum number of simultaneously open files allowed to each
963
        server subprocess. The default is one thousand files. If the kernel is enforcing
964 965 966 967 968 969
        a safe per-process limit, you don't need to worry about this setting.
        But on some platforms (notably, most BSD systems), the kernel will
        allow individual processes to open many more files than the system
        can really support when a large number of processes all try to open
        that many files. If you find yourself seeing <quote>Too many open
        files</> failures, try reducing this setting.
970
        This parameter can only be set at server start.
971 972 973 974
       </para>
      </listitem>
     </varlistentry>
     
975 976
     <varlistentry id="guc-shared-preload-libraries" xreflabel="shared_preload_libraries">
      <term><varname>shared_preload_libraries</varname> (<type>string</type>)</term>
977
      <indexterm>
978
       <primary><varname>shared_preload_libraries</> configuration parameter</primary>
979 980 981 982
      </indexterm>
      <listitem>
       <para>
        This variable specifies one or more shared libraries that are
983 984 985 986 987 988
        to be preloaded at server start. If more than one library is to be
        loaded, separate their names with commas. For example,
        <literal>'$libdir/mylib'</literal> would cause
        <literal>mylib.so</> (or on some platforms,
        <literal>mylib.sl</>) to be preloaded from the installation's
        standard library directory.
989
        This parameter can only be set at server start.
990 991 992 993
       </para>

       <para>
        <productname>PostgreSQL</productname> procedural language
994
        libraries can be preloaded in this way, typically by using the
995
        syntax <literal>'$libdir/plXXX'</literal> where
996 997 998 999 1000
        <literal>XXX</literal> is <literal>pgsql</>, <literal>perl</>,
        <literal>tcl</>, or <literal>python</>.
       </para>

       <para>
1001 1002
        By preloading a shared library, the library startup time is avoided
        when the library is first used.  However, the time to start each new
1003
        server process might increase slightly, even if that process never
1004
        uses the library.  So this parameter is recommended only for
1005 1006 1007
        libraries that will be used in most sessions. 
       </para>

1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018
     <note>
      <para>
        On Windows hosts, preloading a library at server start will not reduce
        the time required to start each new server process; each server process
        will re-load all preload libraries.  However, <varname>shared_preload_libraries
        </varname> is still useful on Windows hosts because some shared libraries may 
        need to perform certain operations that only take place at postmaster start
        (for example, a shared library may need to reserve lightweight locks
        or shared memory and you can't do that after the postmaster has started).
       </para>
      </note>
1019 1020 1021 1022 1023
       <para>
        If a specified library is not found,
        the server will fail to start.
       </para>

1024 1025 1026 1027 1028
       <para>
        Every  PostgreSQL-supported library has a <quote>magic
        block</> that is checked to guarantee compatibility.  
        For this reason, non-PostgreSQL libraries cannot be 
        loaded in this way.
1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081
       </para>
      </listitem>
     </varlistentry>

     </variablelist>
    </sect2>

    <sect2 id="runtime-config-resource-vacuum-cost">
     <title id="runtime-config-resource-vacuum-cost-title">
       Cost-Based Vacuum Delay
     </title>

     <para>
      During the execution of <xref linkend="sql-vacuum"
      endterm="sql-vacuum-title"> and <xref linkend="sql-analyze"
      endterm="sql-analyze-title"> commands, the system maintains an
      internal counter that keeps track of the estimated cost of the
      various I/O operations that are performed.  When the accumulated
      cost reaches a limit (specified by
      <varname>vacuum_cost_limit</varname>), the process performing
      the operation will sleep for a while (specified by
      <varname>vacuum_cost_delay</varname>). Then it will reset the
      counter and continue execution.
     </para>

     <para>
      The intent of this feature is to allow administrators to reduce
      the I/O impact of these commands on concurrent database
      activity. There are many situations in which it is not very
      important that maintenance commands like
      <command>VACUUM</command> and <command>ANALYZE</command> finish
      quickly; however, it is usually very important that these
      commands do not significantly interfere with the ability of the
      system to perform other database operations. Cost-based vacuum
      delay provides a way for administrators to achieve this.
     </para>

     <para>
      This feature is disabled by default. To enable it, set the
      <varname>vacuum_cost_delay</varname> variable to a nonzero
      value.
     </para>

     <variablelist>
      <varlistentry id="guc-vacuum-cost-delay" xreflabel="vacuum_cost_delay">
       <term><varname>vacuum_cost_delay</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>vacuum_cost_delay</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         The length of time, in milliseconds, that the process will sleep
         when the cost limit has been exceeded.
1082
         The default value is zero, which disables the cost-based vacuum
1083 1084 1085 1086
         delay feature.  Positive values enable cost-based vacuuming.
         Note that on many systems, the effective resolution
         of sleep delays is 10 milliseconds; setting
         <varname>vacuum_cost_delay</varname> to a value that is
1087
         not a multiple of 10 might have the same results as setting it
1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102
         to the next higher multiple of 10.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-vacuum-cost-page-hit" xreflabel="vacuum_cost_page_hit">
       <term><varname>vacuum_cost_page_hit</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>vacuum_cost_page_hit</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         The estimated cost for vacuuming a buffer found in the shared buffer
         cache. It represents the cost to lock the buffer pool, lookup
         the shared hash table and scan the content of the page. The
1103
         default value is one.
1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-vacuum-cost-page-miss" xreflabel="vacuum_cost_page_miss">
       <term><varname>vacuum_cost_page_miss</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>vacuum_cost_page_miss</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         The estimated cost for vacuuming a buffer that has to be read from
         disk.  This represents the effort to lock the buffer pool,
         lookup the shared hash table, read the desired block in from
         the disk and scan its content. The default value is 10.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-vacuum-cost-page-dirty" xreflabel="vacuum_cost_page_dirty">
       <term><varname>vacuum_cost_page_dirty</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>vacuum_cost_page_dirty</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         The estimated cost charged when vacuum modifies a block that was
         previously clean. It represents the extra I/O required to
         flush the dirty block out to disk again. The default value is
         20.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-vacuum-cost-limit" xreflabel="vacuum_cost_limit">
       <term><varname>vacuum_cost_limit</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>vacuum_cost_limit</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         The accumulated cost that will cause the vacuuming process to sleep.
         The default value is 200.
        </para>
       </listitem>
      </varlistentry>
     </variablelist>

     <note>
      <para>
       There are certain operations that hold critical locks and should
       therefore complete as quickly as possible.  Cost-based vacuum
       delays do not occur during such operations.  Therefore it is
       possible that the cost accumulates far higher than the specified
       limit.  To avoid uselessly long delays in such cases, the actual
       delay is calculated as <varname>vacuum_cost_delay</varname> *
       <varname>accumulated_balance</varname> /
       <varname>vacuum_cost_limit</varname> with a maximum of
       <varname>vacuum_cost_delay</varname> * 4.
      </para>
     </note>
    </sect2>

    <sect2 id="runtime-config-resource-background-writer">
     <title>Background Writer</title>

     <para>
      Beginning in <productname>PostgreSQL</> 8.0, there is a separate server
1172
      process called the <firstterm>background writer</>, whose function
1173 1174 1175
      is to issue writes of <quote>dirty</> shared buffers.  The intent is
      that server processes handling user queries should seldom or never have
      to wait for a write to occur, because the background writer will do it.
1176
      However there is a net overall
1177 1178 1179 1180
      increase in I/O load, because where a repeatedly-dirtied page might
      before have been written only once per checkpoint interval, the
      background writer might write it several times in the same interval.
      In most situations a continuous low load is preferable to periodic
1181 1182
      spikes, but the parameters discussed in this subsection can be used to
      tune the behavior for local needs.
1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196
     </para>

     <variablelist>
      <varlistentry id="guc-bgwriter-delay" xreflabel="bgwriter_delay">
       <term><varname>bgwriter_delay</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>bgwriter_delay</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         Specifies the delay between activity rounds for the
         background writer.  In each round the writer issues writes
         for some number of dirty buffers (controllable by the
         following parameters).  It then sleeps for <varname>bgwriter_delay</>
1197 1198 1199 1200
         milliseconds, and repeats.  The default value is 200 milliseconds
         (<literal>200ms</>). Note that on many systems, the effective
         resolution of sleep delays is 10 milliseconds; setting
         <varname>bgwriter_delay</> to a value that is not a multiple of
1201
         10 might have the same results as setting it to the next higher
1202 1203
         multiple of 10.  This parameter can only be set in the
         <filename>postgresql.conf</> file or on the server command line.
1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-bgwriter-lru-percent" xreflabel="bgwriter_lru_percent">
       <term><varname>bgwriter_lru_percent</varname> (<type>floating point</type>)</term>
       <indexterm>
        <primary><varname>bgwriter_lru_percent</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         To reduce the probability that server processes will need to issue
         their own writes, the background writer tries to write buffers that
         are likely to be recycled soon.  In each round, it examines up to
         <varname>bgwriter_lru_percent</> of the buffers that are nearest to
         being recycled, and writes any that are dirty.
1220
         The default value is 1.0 (1% of the total number of shared buffers).
1221 1222
         This parameter can only be set in the <filename>postgresql.conf</>
         file or on the server command line.
1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="guc-bgwriter-lru-maxpages" xreflabel="bgwriter_lru_maxpages">
       <term><varname>bgwriter_lru_maxpages</varname> (<type>integer</type>)</term>
       <indexterm>
        <primary><varname>bgwriter_lru_maxpages</> configuration parameter</primary>
       </indexterm>
       <listitem>
        <para>
         In each round, no more than this many buffers will be written
         as a result of scanning soon-to-be-recycled buffers.
1236
         The default value is five buffers.
1237 1238
         This parameter can only be set in the <filename>postgresql.conf</>
         file or on the server command line.
1239 1240 1241 1242 1243 1244
        </para>
       </listitem>
      </varlistentry>
     </variablelist>

     <para>
1245
      Smaller values of <varname>bgwriter_lru_percent</varname> and
1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258
      <varname>bgwriter_lru_maxpages</varname> reduce the extra I/O load
      caused by the background writer, but make it more likely that server
      processes will have to issue writes for themselves, delaying interactive
      queries.
     </para>
    </sect2>
   </sect1>

   <sect1 id="runtime-config-wal">
    <title>Write Ahead Log</title>

   <para>
    See also <xref linkend="wal-configuration"> for details on WAL
1259
    and checkpoint tuning.
1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272
   </para>

    <sect2 id="runtime-config-wal-settings">
     <title>Settings</title>
     <variablelist>
     
     <varlistentry id="guc-fsync" xreflabel="fsync">
      <indexterm>
       <primary><varname>fsync</> configuration parameter</primary>
      </indexterm>
      <term><varname>fsync</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
1273
        If this parameter is on, the <productname>PostgreSQL</> server
1274 1275 1276 1277
        will try to make sure that updates are physically written to
        disk, by issuing <function>fsync()</> system calls or various
        equivalent methods (see <xref linkend="guc-wal-sync-method">).
        This ensures that the database cluster can recover to a
1278 1279 1280 1281
        consistent state after an operating system or hardware crash.
       </para>

       <para>
1282
        However, using <varname>fsync</varname> results in a
1283 1284 1285 1286 1287 1288 1289
        performance penalty: when a transaction is committed,
        <productname>PostgreSQL</productname> must wait for the
        operating system to flush the write-ahead log to disk.  When
        <varname>fsync</varname> is disabled, the operating system is
        allowed to do its best in buffering, ordering, and delaying
        writes. This can result in significantly improved performance.
        However, if the system crashes, the results of the last few
1290 1291
        committed transactions might be lost in part or whole. In the
        worst case, unrecoverable data corruption might occur.
1292
        (Crashes of the database software itself are <emphasis>not</>
1293 1294 1295 1296 1297 1298 1299 1300
        a risk factor here.  Only an operating-system-level crash
        creates a risk of corruption.)
       </para>

       <para>
        Due to the risks involved, there is no universally correct
        setting for <varname>fsync</varname>. Some administrators
        always disable <varname>fsync</varname>, while others only
1301 1302
        turn it off during initial bulk data loads, where there is a clear
        restart point if something goes wrong.  Others
1303 1304 1305 1306 1307 1308 1309
        always leave <varname>fsync</varname> enabled. The default is
        to enable <varname>fsync</varname>, for maximum reliability.
        If you trust your operating system, your hardware, and your
        utility company (or your battery backup), you can consider
        disabling <varname>fsync</varname>.
       </para>

1310 1311 1312 1313 1314 1315 1316
       <para>
        In many situations, turning off <xref linkend="guc-synchronous-commit">
        for noncritical transactions can provide much of the potential
        performance benefit of turning off <varname>fsync</varname>, without
        the attendant risks of data corruption.
       </para>

1317
       <para>
1318 1319 1320
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
        If you turn this parameter off, also consider turning off 
1321
        <xref linkend="guc-full-page-writes">.
1322 1323 1324
       </para>
      </listitem>
     </varlistentry>
1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356

     <varlistentry id="guc-synchronous-commit" xreflabel="synchronous_commit">
      <term><varname>synchronous_commit</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>synchronous_commit</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies whether transaction commit will wait for WAL records
        to be written to disk before the command returns a <quote>success</>
        indication to the client.  The default, and safe, setting is
        <literal>on</>.  When <literal>off</>, there can be a delay between
        when success is reported to the client and when the transaction is
        really guaranteed to be safe against a server crash.  (The maximum
        delay is three times <xref linkend="guc-wal-writer-delay">.)  Unlike
        <xref linkend="guc-fsync">, setting this parameter to <literal>off</>
        does not create any risk of database inconsistency: a crash might
        result in some recent allegedly-committed transactions being lost, but
        the database state will be just the same as if those transactions had
        been aborted cleanly.  So, turning <varname>synchronous_commit</> off
        can be a useful alternative when performance is more important than
        exact certainty about the durability of a transaction.  For more
        discussion see <xref linkend="wal-async-commit">.
       </para>
       <para>
        This parameter can be changed at any time; the behavior for any
        one transaction is determined by the setting in effect when it
        commits.  It is therefore possible, and useful, to have some
        transactions commit synchronously and others asynchronously.
       </para>
      </listitem>
     </varlistentry>
1357 1358 1359 1360 1361 1362 1363 1364
     
     <varlistentry id="guc-wal-sync-method" xreflabel="wal_sync_method">
      <term><varname>wal_sync_method</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>wal_sync_method</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
1365 1366 1367 1368
        Method used for forcing WAL updates out to disk.
        If <varname>fsync</varname> is off then this setting is irrelevant,
        since updates will not be forced out at all.
        Possible values are:
1369 1370 1371 1372 1373 1374 1375 1376 1377
       </para>
       <itemizedlist>
        <listitem>
        <para>
         <literal>open_datasync</> (write WAL files with <function>open()</> option <symbol>O_DSYNC</>)
        </para>
        </listitem>
        <listitem>
        <para>
1378
         <literal>fdatasync</> (call <function>fdatasync()</> at each commit)
1379 1380 1381 1382
        </para>
        </listitem>
        <listitem>
        <para>
1383
         <literal>fsync_writethrough</> (call <function>fsync()</> at each commit, forcing write-through of any disk write cache)
1384 1385 1386 1387
        </para>
        </listitem>
        <listitem>
        <para>
1388
         <literal>fsync</> (call <function>fsync()</> at each commit)
1389 1390 1391 1392 1393 1394 1395 1396 1397 1398
        </para>
        </listitem>
        <listitem>
        <para>
         <literal>open_sync</> (write WAL files with <function>open()</> option <symbol>O_SYNC</>)
        </para>
        </listitem>
       </itemizedlist>
       <para>
        Not all of these choices are available on all platforms.
1399 1400
        The default is the first method in the above list that is supported
        by the platform.
1401
        The <literal>open_</>* options also use <literal>O_DIRECT</> if available.
1402 1403
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414
       </para>
      </listitem>
     </varlistentry>
     
     <varlistentry id="guc-full-page-writes" xreflabel="full_page_writes">
      <indexterm>
       <primary><varname>full_page_writes</> configuration parameter</primary>
      </indexterm>
      <term><varname>full_page_writes</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
1415
        When this parameter is on, the <productname>PostgreSQL</> server
1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429
        writes the entire content of each disk page to WAL during the
        first modification of that page after a checkpoint.
        This is needed because
        a page write that is in process during an operating system crash might
        be only partially completed, leading to an on-disk page
        that contains a mix of old and new data.  The row-level change data
        normally stored in WAL will not be enough to completely restore
        such a page during post-crash recovery.  Storing the full page image
        guarantees that the page can be correctly restored, but at a price
        in increasing the amount of data that must be written to WAL.
        (Because WAL replay always starts from a checkpoint, it is sufficient
        to do this during the first change of each page after a checkpoint.
        Therefore, one way to reduce the cost of full-page writes is to
        increase the checkpoint interval parameters.)
1430 1431 1432
       </para>

       <para>
1433
        Turning this parameter off speeds normal operation, but
1434 1435
        might lead to a corrupt database after an operating system crash
        or power failure. The risks are similar to turning off
1436
        <varname>fsync</>, though smaller.  It might be safe to turn off
1437
        this parameter if you have hardware (such as a battery-backed disk
Peter Eisentraut's avatar
Peter Eisentraut committed
1438 1439
        controller) or file-system software that reduces
        the risk of partial page writes to an acceptably low level (e.g., ReiserFS 4).
1440 1441 1442
       </para>

       <para>
1443
        Turning off this parameter does not affect use of
1444
        WAL archiving for point-in-time recovery (PITR)
1445
        (see <xref linkend="continuous-archiving">).
1446 1447 1448
       </para>

       <para>
1449 1450 1451
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
        The default is <literal>on</>.
1452 1453 1454
       </para>
      </listitem>
     </varlistentry>
1455

1456 1457 1458 1459 1460 1461 1462
     <varlistentry id="guc-wal-buffers" xreflabel="wal_buffers">
      <term><varname>wal_buffers</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>wal_buffers</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
1463 1464 1465 1466 1467 1468
        The amount of memory used in shared memory for WAL data.  The
        default is 64 kilobytes (<literal>64kB</>).  The setting need only
        be large enough to hold the amount of WAL data generated by one
        typical transaction, since the data is written out to disk at
        every transaction commit.  This parameter can only be set at server
        start.
1469 1470 1471
       </para>

       <para>
1472
        Increasing this parameter might cause <productname>PostgreSQL</>
1473 1474 1475 1476 1477 1478 1479
        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>
1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500

     <varlistentry id="guc-wal-writer-delay" xreflabel="wal_writer_delay">
      <term><varname>wal_writer_delay</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>wal_writer_delay</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the delay between activity rounds for the WAL writer.
        In each round the writer will flush WAL to disk. It then sleeps for
        <varname>wal_writer_delay</> milliseconds, and repeats.  The default
        value is 200 milliseconds (<literal>200ms</>).  Note that on many
        systems, the effective resolution of sleep delays is 10 milliseconds;
        setting <varname>wal_writer_delay</> to a value that is not a multiple
        of 10 might have the same results as setting it to the next higher
        multiple of 10. This parameter can only be set in the
        <filename>postgresql.conf</> file or on the server command line.
       </para>
      </listitem>
     </varlistentry>

1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533
     <varlistentry id="guc-commit-delay" xreflabel="commit_delay">
      <term><varname>commit_delay</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>commit_delay</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Time delay between writing a commit record to the WAL buffer
        and flushing the buffer out to disk, in microseconds. A
        nonzero delay can allow multiple transactions to be committed
        with only one <function>fsync()</function> system call, if
        system load is high enough that additional transactions become
        ready to commit within the given interval. But the delay is
        just wasted if no other transactions become ready to
        commit. Therefore, the delay is only performed if at least
        <varname>commit_siblings</varname> other transactions are
        active at the instant that a server process has written its
        commit record. The default is zero (no delay).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-commit-siblings" xreflabel="commit_siblings">
      <term><varname>commit_siblings</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>commit_siblings</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Minimum number of concurrent open transactions to require
        before performing the <varname>commit_delay</> delay. A larger
        value makes it more probable that at least one other
        transaction will become ready to commit during the delay
1534
        interval. The default is five transactions.
1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553
       </para>
      </listitem>
     </varlistentry>

     </variablelist>
     </sect2>
     <sect2 id="runtime-config-wal-checkpoints">
     <title>Checkpoints</title>

    <variablelist>
     <varlistentry id="guc-checkpoint-segments" xreflabel="checkpoint_segments">
      <term><varname>checkpoint_segments</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>checkpoint_segments</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Maximum distance between automatic WAL checkpoints, in log
        file segments (each segment is normally 16 megabytes). The
1554
        default is three segments.
1555 1556
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-checkpoint-timeout" xreflabel="checkpoint_timeout">
      <term><varname>checkpoint_timeout</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>checkpoint_timeout</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Maximum time between automatic WAL checkpoints, in
1569
        seconds. The default is five minutes (<literal>5min</>).
1570 1571
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
1572 1573 1574 1575
       </para>
      </listitem>
     </varlistentry>

1576 1577 1578 1579 1580 1581 1582
     <varlistentry id="guc-checkpoint-completion-target" xreflabel="checkpoint_completion_target">
      <term><varname>checkpoint_completion_target</varname> (<type>floating point</type>)</term>
      <indexterm>
       <primary><varname>checkpoint_completion_target</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
1583
        Specifies the target length of checkpoints, as a fraction of
1584 1585 1586 1587 1588 1589 1590 1591
        the checkpoint interval. The default is 0.5.

        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
       </para>
      </listitem>
     </varlistentry>

1592 1593 1594 1595 1596 1597 1598 1599 1600
     <varlistentry id="guc-checkpoint-warning" xreflabel="checkpoint_warning">
      <term><varname>checkpoint_warning</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>checkpoint_warning</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Write a message to the server log if checkpoints caused by
        the filling of checkpoint segment files happen closer together
1601 1602
        than this many seconds (which suggests that
        <varname>checkpoint_segments</> ought to be raised).  The default is
1603
        30 seconds (<literal>30s</>).  Zero disables the warning.
1604 1605
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625
       </para>
      </listitem>
     </varlistentry>

     </variablelist>
     </sect2>
     <sect2 id="runtime-config-wal-archiving">
     <title>Archiving</title>

    <variablelist>
     <varlistentry id="guc-archive-command" xreflabel="archive_command">
      <term><varname>archive_command</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>archive_command</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        The shell command to execute to archive a completed segment of
        the WAL file series. If this is an empty string (the default),
        WAL archiving is disabled. Any <literal>%p</> in the string is
1626 1627 1628 1629 1630
        replaced by the path name of the file to archive, and any
        <literal>%f</> is replaced by the file name only.
        (The path name is relative to the working directory of the server,
        i.e., the cluster's data directory.)
        Use <literal>%%</> to embed an actual <literal>%</> character in the
1631
        command. For more information see <xref
1632 1633 1634
        linkend="backup-archiving-wal">.
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646
       </para>
       <para>
        It is important for the command to return a zero exit status if
        and only if it succeeds.  Examples:
<programlisting>
archive_command = 'cp "%p" /mnt/server/archivedir/"%f"'
archive_command = 'copy "%p" /mnt/server/archivedir/"%f"'  # Windows
</programlisting>
       </para>
      </listitem>
     </varlistentry>
     
1647 1648 1649 1650 1651 1652 1653
     <varlistentry id="guc-archive-timeout" xreflabel="archive_timeout">
      <term><varname>archive_timeout</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>archive_timeout</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666
        The <xref linkend="guc-archive-command"> is only invoked on
        completed WAL segments. Hence, if your server generates little WAL
        traffic (or has slack periods where it does so), there could be a
        long delay between the completion of a transaction and its safe
        recording in archive storage.  To put a limit on how old unarchived
        data can be, you can set <varname>archive_timeout</> to force the
        server to switch to a new WAL segment file periodically.  When this
        parameter is greater than zero, the server will switch to a new
        segment file whenever this many seconds have elapsed since the last
        segment file switch.  Note that archived files that are closed early
        due to a forced switch are still the same length as completely full
        files.  Therefore, it is unwise to use a very short
        <varname>archive_timeout</> &mdash; it will bloat your archive
1667
        storage.  <varname>archive_timeout</> settings of a minute or so are
1668 1669
        usually reasonable.  This parameter can only be set in the
        <filename>postgresql.conf</> file or on the server command line.
1670 1671 1672 1673
       </para>
      </listitem>
     </varlistentry>
     
1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687
     </variablelist>
    </sect2>
   </sect1>

   <sect1 id="runtime-config-query">
    <title>Query Planning</title>

    <sect2 id="runtime-config-query-enable">
     <title>Planner Method Configuration</title>

      <para>
       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
1688
       is not optimal, a temporary solution can be found by using one
1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846
       of these configuration parameters to force the optimizer to
       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 <xref
       linkend="runtime-config-query-constants"
       endterm="runtime-config-query-constants-title">, running <xref
       linkend="sql-analyze" endterm="sql-analyze-title"> more
       frequently, increasing the value of the <xref
       linkend="guc-default-statistics-target"> configuration parameter,
       and increasing the amount of statistics collected for
       specific columns using <command>ALTER TABLE SET
       STATISTICS</command>.
      </para>

     <variablelist>
     <varlistentry id="guc-enable-bitmapscan" xreflabel="enable_bitmapscan">
      <term><varname>enable_bitmapscan</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary>bitmap scan</primary>
      </indexterm>
      <indexterm>
       <primary><varname>enable_bitmapscan</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Enables or disables the query planner's use of bitmap-scan plan
        types. The default is <literal>on</>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-enable-hashagg" xreflabel="enable_hashagg">
      <term><varname>enable_hashagg</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>enable_hashagg</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Enables or disables the query planner's use of hashed
        aggregation plan types. The default is <literal>on</>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-enable-hashjoin" xreflabel="enable_hashjoin">
      <term><varname>enable_hashjoin</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>enable_hashjoin</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Enables or disables the query planner's use of hash-join plan
        types. The default is <literal>on</>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-enable-indexscan" xreflabel="enable_indexscan">
      <term><varname>enable_indexscan</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary>index scan</primary>
      </indexterm>
      <indexterm>
       <primary><varname>enable_indexscan</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Enables or disables the query planner's use of index-scan plan
        types. The default is <literal>on</>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-enable-mergejoin" xreflabel="enable_mergejoin">
      <term><varname>enable_mergejoin</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>enable_mergejoin</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Enables or disables the query planner's use of merge-join plan
        types. The default is <literal>on</>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-enable-nestloop" xreflabel="enable_nestloop">
      <term><varname>enable_nestloop</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>enable_nestloop</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Enables or disables the query planner's use of nested-loop join
        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
        <literal>on</>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-enable-seqscan" xreflabel="enable_seqscan">
      <term><varname>enable_seqscan</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary>sequential scan</primary>
      </indexterm>
      <indexterm>
       <primary><varname>enable_seqscan</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Enables or disables the query planner's use of sequential scan
        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 <literal>on</>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-enable-sort" xreflabel="enable_sort">
      <term><varname>enable_sort</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>enable_sort</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Enables or disables the query planner's use of explicit sort
        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 <literal>on</>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-enable-tidscan" xreflabel="enable_tidscan">
      <term><varname>enable_tidscan</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>enable_tidscan</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Enables or disables the query planner's use of <acronym>TID</>
        scan plan types. The default is <literal>on</>.
       </para>
      </listitem>
     </varlistentry>
     
     </variablelist>
     </sect2>
     <sect2 id="runtime-config-query-constants">
     <title id="runtime-config-query-constants-title">
      Planner Cost Constants
     </title>

1847 1848 1849 1850 1851 1852 1853 1854 1855 1856 1857 1858
    <para>
     The <firstterm>cost</> variables described in this section are measured
     on an arbitrary scale.  Only their relative values matter, hence
     scaling them all up or down by the same factor will result in no change
     in the planner's choices.  Traditionally, these variables have been
     referenced to sequential page fetches as the unit of cost; that is,
     <varname>seq_page_cost</> is conventionally set to <literal>1.0</>
     and the other cost variables are set with reference to that.  But
     you can use a different scale if you prefer, such as actual execution
     times in milliseconds on a particular machine.
    </para>

1859 1860
   <note>
    <para>
1861 1862 1863 1864 1865
     Unfortunately, there is no well-defined method for determining ideal
     values for the cost variables.  They are best treated as averages over
     the entire mix of queries that a particular installation will get.  This
     means that changing them on the basis of just a few experiments is very
     risky.
1866 1867 1868 1869
    </para>
   </note>

     <variablelist>
1870 1871 1872

     <varlistentry id="guc-seq-page-cost" xreflabel="seq_page_cost">
      <term><varname>seq_page_cost</varname> (<type>floating point</type>)</term>
1873
      <indexterm>
1874
       <primary><varname>seq_page_cost</> configuration parameter</primary>
1875 1876 1877
      </indexterm>
      <listitem>
       <para>
1878 1879
        Sets the planner's estimate of the cost of a disk page fetch
        that is part of a series of sequential fetches.  The default is 1.0.
1880 1881 1882 1883 1884 1885 1886 1887 1888 1889 1890 1891
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-random-page-cost" xreflabel="random_page_cost">
      <term><varname>random_page_cost</varname> (<type>floating point</type>)</term>
      <indexterm>
       <primary><varname>random_page_cost</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the planner's estimate of the cost of a
1892 1893 1894 1895 1896 1897 1898
        non-sequentially-fetched disk page.  The default is 4.0.
        Reducing this value relative to <varname>seq_page_cost</>
        will cause the system to prefer index scans; raising it will
        make index scans look relatively more expensive.  You can raise
        or lower both values together to change the importance of disk I/O
        costs relative to CPU costs, which are described by the following
        parameters.
1899
       </para>
1900 1901 1902 1903 1904 1905 1906 1907 1908 1909 1910 1911 1912

       <tip>
        <para>
         Although the system will let you set <varname>random_page_cost</> to
         less than <varname>seq_page_cost</>, it is not physically sensible
         to do so.  However, setting them equal makes sense if the database
         is entirely cached in RAM, since in that case there is no penalty
         for touching pages out of sequence.  Also, in a heavily-cached
         database you should lower both values relative to the CPU parameters,
         since the cost of fetching a page already in RAM is much smaller
         than it would normally be.
        </para>
       </tip>
1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923
      </listitem>
     </varlistentry>

     <varlistentry id="guc-cpu-tuple-cost" xreflabel="cpu_tuple_cost">
      <term><varname>cpu_tuple_cost</varname> (<type>floating point</type>)</term>
      <indexterm>
       <primary><varname>cpu_tuple_cost</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the planner's estimate of the cost of processing
1924 1925
        each row during a query.
        The default is 0.01.
1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-cpu-index-tuple-cost" xreflabel="cpu_index_tuple_cost">
      <term><varname>cpu_index_tuple_cost</varname> (<type>floating point</type>)</term>
      <indexterm>
       <primary><varname>cpu_index_tuple_cost</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the planner's estimate of the cost of processing
1938
        each index entry during an index scan.
1939
        The default is 0.005.
1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951
       </para>
      </listitem>
     </varlistentry>
    
     <varlistentry id="guc-cpu-operator-cost" xreflabel="cpu_operator_cost">
      <term><varname>cpu_operator_cost</varname> (<type>floating point</type>)</term>
      <indexterm>
       <primary><varname>cpu_operator_cost</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the planner's estimate of the cost of processing each
1952 1953 1954 1955 1956 1957 1958
        operator or function executed during a query.
        The default is 0.0025.
       </para>
      </listitem>
     </varlistentry>
     
     <varlistentry id="guc-effective-cache-size" xreflabel="effective_cache_size">
1959
      <term><varname>effective_cache_size</varname> (<type>integer</type>)</term>
1960 1961 1962 1963 1964 1965
      <indexterm>
       <primary><varname>effective_cache_size</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the planner's assumption about the effective size of the
1966
        disk cache that is available to a single query.  This is
1967 1968 1969 1970 1971 1972 1973
        factored into estimates of the cost of using an index; a
        higher value makes it more likely index scans will be used, a
        lower value makes it more likely sequential scans will be
        used. When setting this parameter you should consider both
        <productname>PostgreSQL</productname>'s shared buffers and the
        portion of the kernel's disk cache that will be used for
        <productname>PostgreSQL</productname> data files.  Also, take
1974 1975
        into account the expected number of concurrent queries on different
        tables, since they will have to share the available
1976 1977
        space.  This parameter has no effect on the size of shared
        memory allocated by <productname>PostgreSQL</productname>, nor
1978 1979
        does it reserve kernel disk cache; it is used only for estimation
        purposes.  The default is 128 megabytes (<literal>128MB</>).
1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022
       </para>
      </listitem>
     </varlistentry>

     </variablelist>

    </sect2>
     <sect2 id="runtime-config-query-geqo">
     <title>Genetic Query Optimizer</title>

     <variablelist>

     <varlistentry id="guc-geqo" xreflabel="geqo">
      <indexterm>
       <primary>genetic query optimization</primary>
      </indexterm>
      <indexterm>
       <primary>GEQO</primary>
       <see>genetic query optimization</see>
      </indexterm>
      <indexterm>
       <primary><varname>geqo</> configuration parameter</primary>
      </indexterm>
      <term><varname>geqo</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
        Enables or disables genetic query optimization, which is an
        algorithm that attempts to do query planning without
        exhaustive searching. This is on by default. The
        <varname>geqo_threshold</varname> variable provides a more
        granular way to disable GEQO for certain classes of queries.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-geqo-threshold" xreflabel="geqo_threshold">
      <term><varname>geqo_threshold</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>geqo_threshold</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Use genetic query optimization to plan queries with at least
2023 2024
        this many <literal>FROM</> items involved. (Note that a
        <literal>FULL OUTER JOIN</> construct counts as only one <literal>FROM</>
2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041
        item.) The default is 12. For simpler queries it is usually best
        to use the deterministic, exhaustive planner, but for queries with
        many tables the deterministic planner takes too long.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-geqo-effort" xreflabel="geqo_effort">
      <term><varname>geqo_effort</varname>
      (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>geqo_effort</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Controls the trade off between planning time and query plan
        efficiency in GEQO. This variable must be an integer in the
2042
        range from 1 to 10. The default value is five. Larger values
2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2078 2079 2080 2081 2082 2083 2084 2085 2086 2087 2088 2089 2090 2091 2092 2093 2094 2095 2096 2097 2098 2099 2100 2101 2102 2103 2104 2105 2106 2107 2108 2109 2110 2111 2112 2113 2114 2115 2116 2117 2118 2119 2120 2121 2122
        increase the time spent doing query planning, but also
        increase the likelihood that an efficient query plan will be
        chosen.
       </para>

       <para>
        <varname>geqo_effort</varname> doesn't actually do anything
        directly; it is only used to compute the default values for
        the other variables that influence GEQO behavior (described
        below). If you prefer, you can set the other parameters by
        hand instead.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-geqo-pool-size" xreflabel="geqo_pool_size">
      <term><varname>geqo_pool_size</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>geqo_pool_size</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Controls the pool size used by GEQO. The pool size is the
        number of individuals in the genetic population.  It must be
        at least two, and useful values are typically 100 to 1000.  If
        it is set to zero (the default setting) then a suitable
        default is chosen based on <varname>geqo_effort</varname> and
        the number of tables in the query.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-geqo-generations" xreflabel="geqo_generations">
      <term><varname>geqo_generations</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>geqo_generations</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Controls the number of generations used by GEQO.  Generations
        specifies the number of iterations of the algorithm.  It must
        be at least one, and useful values are in the same range as
        the pool size.  If it is set to zero (the default setting)
        then a suitable default is chosen based on
        <varname>geqo_pool_size</varname>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-geqo-selection-bias" xreflabel="geqo_selection_bias">
      <term><varname>geqo_selection_bias</varname> (<type>floating point</type>)</term>
      <indexterm>
       <primary><varname>geqo_selection_bias</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Controls the selection bias used by GEQO. The selection bias
        is the selective pressure within the population. Values can be
        from 1.50 to 2.00; the latter is the default.
       </para>
      </listitem>
     </varlistentry>
     
     </variablelist>
    </sect2>
     <sect2 id="runtime-config-query-other">
     <title>Other Planner Options</title>

     <variablelist>

     <varlistentry id="guc-default-statistics-target" xreflabel="default_statistics_target">
      <term><varname>default_statistics_target</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>default_statistics_target</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the default statistics target for table columns that have
        not had a column-specific target set via <command>ALTER TABLE
        SET STATISTICS</>.  Larger values increase the time needed to
2123
        do <command>ANALYZE</>, but might improve the quality of the
2124 2125 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141
        planner's estimates. The default is 10. For more information
        on the use of statistics by the <productname>PostgreSQL</>
        query planner, refer to <xref linkend="planner-stats">.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-constraint-exclusion" xreflabel="constraint_exclusion">
      <term><varname>constraint_exclusion</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary>constraint exclusion</primary>
      </indexterm>
      <indexterm>
       <primary><varname>constraint_exclusion</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Enables or disables the query planner's use of table constraints to
2142
        optimize queries.  The default is <literal>off</>.
2143 2144 2145
       </para>

       <para>
2146 2147
        When this parameter is <literal>on</>, the planner compares
        query conditions with table <literal>CHECK</> constraints, and
2148
        omits scanning tables for which the conditions contradict the
2149
        constraints.  For example:
2150 2151 2152 2153 2154 2155 2156 2157 2158

<programlisting>
CREATE TABLE parent(key integer, ...);
CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent);
CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent);
...
SELECT * FROM parent WHERE key = 2400;
</programlisting>

2159 2160 2161 2162
        With constraint exclusion enabled, this <command>SELECT</>
        will not scan <structname>child1000</> at all.  This can
        improve performance when inheritance is used to build
        partitioned tables.
2163 2164 2165
       </para>

       <para>
2166
        Currently, <varname>constraint_exclusion</> is disabled by
2167
        default because the constraint checks are relatively
2168
        expensive, and in many circumstances will yield no savings.
2169 2170 2171 2172 2173 2174
        It is recommended to turn this on only if you are actually
        using partitioned tables designed to take advantage of the
        feature.
       </para>

       <para>
2175
        Refer to <xref linkend="ddl-partitioning"> for more information
2176
        on using constraint exclusion and partitioning.
2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-from-collapse-limit" xreflabel="from_collapse_limit">
      <term><varname>from_collapse_limit</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>from_collapse_limit</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        The planner will merge sub-queries into upper queries if the
        resulting <literal>FROM</literal> list would have no more than
2190
        this many items.  Smaller values reduce planning time but might
2191
        yield inferior query plans.  The default is eight.  It is usually
2192
        wise to keep this less than <xref linkend="guc-geqo-threshold">.
2193
        For more information see <xref linkend="explicit-joins">.
2194 2195 2196 2197 2198 2199 2200 2201 2202 2203 2204
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-join-collapse-limit" xreflabel="join_collapse_limit">
      <term><varname>join_collapse_limit</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>join_collapse_limit</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
2205 2206 2207
        The planner will rewrite explicit <literal>JOIN</>
        constructs (except <literal>FULL JOIN</>s) into lists of
        <literal>FROM</> items whenever a list of no more than this many items
2208
        would result.  Smaller values reduce planning time but might
2209
        yield inferior query plans.
2210 2211 2212 2213 2214 2215
       </para>

       <para>
        By default, this variable is set the same as
        <varname>from_collapse_limit</varname>, which is appropriate
        for most uses. Setting it to 1 prevents any reordering of
2216
        explicit <literal>JOIN</>s. Thus, the explicit join order
2217 2218
        specified in the query will be the actual order in which the
        relations are joined. The query planner does not always choose
2219
        the optimal join order; advanced users can elect to
2220
        temporarily set this variable to 1, and then specify the join
2221 2222
        order they desire explicitly.
        For more information see <xref linkend="explicit-joins">.
2223 2224 2225
       </para>
      </listitem>
     </varlistentry>
2226

2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238
     </variablelist>
    </sect2>
   </sect1>

   <sect1 id="runtime-config-logging">
    <title>Error Reporting and Logging</title>

    <indexterm zone="runtime-config-logging">
     <primary>server log</primary>
    </indexterm>

    <sect2 id="runtime-config-logging-where">
2239
     <title>Where To Log</title>
2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255

     <indexterm zone="runtime-config-logging-where">
      <primary>where to log</primary>
     </indexterm>

     <variablelist>

     <varlistentry id="guc-log-destination" xreflabel="log_destination">
      <term><varname>log_destination</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>log_destination</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        <productname>PostgreSQL</productname> supports several methods
         for logging server messages, including
2256
         <systemitem>stderr</systemitem>, <systemitem>csvlog</systemitem> and
2257 2258
         <systemitem>syslog</systemitem>. On Windows, 
         <systemitem>eventlog</systemitem> is also supported. Set this
2259
         parameter to a list of desired log destinations separated by
2260 2261
         commas. The default is to log to <systemitem>stderr</systemitem> 
         only.
2262 2263
         This parameter can only be set in the <filename>postgresql.conf</>
         file or on the server command line.
2264
       </para>
2265 2266 2267 2268 2269 2270 2271
       <para>
        If <systemitem>csvlog</> is included in <varname>log_destination</>,
        log entries are output in <quote>comma separated
        value</> format, which is convenient for loading them into programs.
        See <xref linkend="runtime-config-logging-csvlog"> for details.
        <varname>logging_collector</varname> must be enabled to generate 
        CSV-format log output.
2272
       </para>
2273 2274 2275
      </listitem>
     </varlistentry>

2276 2277
     <varlistentry id="guc-logging-collector" xreflabel="logging_collector">
      <term><varname>logging_collector</varname> (<type>boolean</type>)</term>
2278
      <indexterm>
2279
       <primary><varname>logging_collector</> configuration parameter</primary>
2280 2281 2282
      </indexterm>
      <listitem>
       <para>
2283
         This parameter allows messages sent to <application>stderr</>,
2284
         and CSV-format log output, to be
2285
         captured and redirected into log files.
2286
         This approach is often more useful than
2287
         logging to <application>syslog</>, since some types of messages
2288
         might not appear in <application>syslog</> output (a common example
2289
         is dynamic-linker failure messages).
2290
         This parameter can only be set at server start.
2291 2292 2293 2294 2295 2296 2297 2298 2299 2300 2301
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-log-directory" xreflabel="log_directory">
      <term><varname>log_directory</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>log_directory</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
2302 2303
        When <varname>logging_collector</> is enabled, 
        this parameter determines the directory in which log files will be created.
2304
        It can be specified as an absolute path, or relative to the
2305
        cluster data directory.
2306 2307
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
2308 2309 2310 2311 2312 2313 2314 2315 2316 2317 2318
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-log-filename" xreflabel="log_filename">
      <term><varname>log_filename</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>log_filename</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
2319 2320
        When <varname>logging_collector</varname> is enabled,
        this parameter sets the file names of the created log files.  The value
2321
        is treated as a <systemitem>strftime</systemitem> pattern,
2322 2323 2324 2325
        so <literal>%</literal>-escapes can be used to specify time-varying
        file names.  (Note that if there are
        any time-zone-dependent <literal>%</literal>-escapes, the computation
        is done in the zone specified by <xref linkend="guc-log-timezone">.)
2326
        If no <literal>%</literal>-escapes are present,
2327 2328 2329 2330
        <productname>PostgreSQL</productname> will append the epoch of the new
        log file's creation time.  For example, if
        <varname>log_filename</varname> were <literal>server_log</literal>,
        then the chosen file name would be <literal>server_log.1093827753</>
2331
        for a log starting at Sun Aug 29 19:02:33 2004 MST.
2332 2333
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
2334
       </para>
2335
       <para>
2336
        If CSV-format output is enabled in <varname>log_destination</>,
Bruce Momjian's avatar
Bruce Momjian committed
2337
        <literal>.csv</> will be appended to the timestamped 
2338 2339 2340 2341 2342
        log file name to create the file name for CSV-format output.
        (If <varname>log_filename</> ends in <literal>.log</>, the suffix is
        replaced instead.)
        In the case of the example above, the CSV
        file name will be <literal>server_log.1093827753.csv</literal>.
2343
       </para>
2344 2345 2346 2347 2348 2349 2350 2351 2352 2353
      </listitem>
     </varlistentry>

     <varlistentry id="guc-log-rotation-age" xreflabel="log_rotation_age">
      <term><varname>log_rotation_age</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>log_rotation_age</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
2354 2355
        When <varname>logging_collector</varname> is enabled,
        this parameter determines the maximum lifetime of an individual log file.
2356 2357 2358
        After this many minutes have elapsed, a new log file will
        be created.  Set to zero to disable time-based creation of
        new log files.
2359 2360
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
2361 2362 2363 2364 2365 2366 2367 2368 2369 2370 2371
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-log-rotation-size" xreflabel="log_rotation_size">
      <term><varname>log_rotation_size</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>log_rotation_size</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
2372 2373
        When <varname>logging_collector</varname> is enabled,
        this parameter determines the maximum size of an individual log file.
2374 2375 2376
        After this many kilobytes have been emitted into a log file,
        a new log file will be created.  Set to zero to disable size-based
        creation of new log files.
2377 2378
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
2379 2380 2381 2382 2383 2384 2385 2386 2387 2388 2389
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-log-truncate-on-rotation" xreflabel="log_truncate_on_rotation">
      <term><varname>log_truncate_on_rotation</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>log_truncate_on_rotation</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
2390 2391
        When <varname>logging_collector</varname> is enabled,
        this parameter will cause <productname>PostgreSQL</productname> to truncate (overwrite),
2392 2393 2394 2395
        rather than append to, any existing log file of the same name.
        However, truncation will occur only when a new file is being opened
        due to time-based rotation, not during server startup or size-based
        rotation.  When off, pre-existing files will be appended to in
2396
        all cases.  For example, using this setting in combination with
2397 2398 2399
        a <varname>log_filename</varname> like <literal>postgresql-%H.log</literal>
        would result in generating twenty-four hourly log files and then
        cyclically overwriting them.
2400 2401
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
2402 2403 2404 2405 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418
       </para>
       <para>
        Example:  To keep 7 days of logs, one log file per day named
        <literal>server_log.Mon</literal>, <literal>server_log.Tue</literal>, 
        etc, and automatically overwrite last week's log with this week's log,
        set <varname>log_filename</varname> to <literal>server_log.%a</literal>, 
        <varname>log_truncate_on_rotation</varname> to <literal>on</literal>, and 
        <varname>log_rotation_age</varname> to <literal>1440</literal>.
       </para>
       <para>
        Example: To keep 24 hours of logs, one log file per hour, but 
        also rotate sooner if the log file size exceeds 1GB, set 
        <varname>log_filename</varname> to <literal>server_log.%H%M</literal>, 
        <varname>log_truncate_on_rotation</varname> to <literal>on</literal>, 
        <varname>log_rotation_age</varname> to <literal>60</literal>, and 
        <varname>log_rotation_size</varname> to <literal>1000000</literal>.
        Including <literal>%M</> in <varname>log_filename</varname> allows
2419
        any size-driven rotations that might occur to select a file name
2420
        different from the hour's initial file name.
2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-syslog-facility" xreflabel="syslog_facility">
      <term><varname>syslog_facility</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>syslog_facility</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
2432
        When logging to <application>syslog</> is enabled, this parameter
2433
        determines the <application>syslog</application>
2434
        <quote>facility</quote> to be used.  You can choose
2435 2436 2437 2438 2439 2440
        from <literal>LOCAL0</>, <literal>LOCAL1</>,
        <literal>LOCAL2</>, <literal>LOCAL3</>, <literal>LOCAL4</>,
        <literal>LOCAL5</>, <literal>LOCAL6</>, <literal>LOCAL7</>;
        the default is <literal>LOCAL0</>. See also the
        documentation of your system's
        <application>syslog</application> daemon.
2441 2442
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
2443 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453
       </para>
      </listitem>
     </varlistentry>
     
     <varlistentry id="guc-syslog-ident" xreflabel="syslog_ident">
      <term><varname>syslog_ident</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>syslog_identity</> configuration parameter</primary>
      </indexterm>
       <listitem>
        <para>
2454
         When logging to <application>syslog</> is enabled, this parameter
2455 2456 2457 2458
         determines the program name used to identify
         <productname>PostgreSQL</productname> messages in
         <application>syslog</application> logs. The default is
         <literal>postgres</literal>.
2459 2460
         This parameter can only be set in the <filename>postgresql.conf</>
         file or on the server command line.
2461 2462 2463 2464 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 2476 2477 2478 2479 2480 2481 2482
        </para>
       </listitem>
      </varlistentry>
      
      </variablelist>
    </sect2>
     <sect2 id="runtime-config-logging-when">
     <title>When To Log</title>

     <variablelist>

     <varlistentry id="guc-client-min-messages" xreflabel="client_min_messages">
      <term><varname>client_min_messages</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>client_min_messages</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Controls which message levels are sent to the client.
        Valid values are <literal>DEBUG5</>,
        <literal>DEBUG4</>, <literal>DEBUG3</>, <literal>DEBUG2</>,
        <literal>DEBUG1</>, <literal>LOG</>, <literal>NOTICE</>,
2483 2484
        <literal>WARNING</>, <literal>ERROR</>, <literal>FATAL</>,
        and <literal>PANIC</>.  Each level
2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2535 2536 2537 2538
        includes all the levels that follow it.  The later the level,
        the fewer messages are sent.  The default is
        <literal>NOTICE</>.  Note that <literal>LOG</> has a different
        rank here than in <varname>log_min_messages</>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-log-min-messages" xreflabel="log_min_messages">
      <term><varname>log_min_messages</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>log_min_messages</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Controls which message levels are written to the server log.
        Valid values are <literal>DEBUG5</>, <literal>DEBUG4</>,
        <literal>DEBUG3</>, <literal>DEBUG2</>, <literal>DEBUG1</>,
        <literal>INFO</>, <literal>NOTICE</>, <literal>WARNING</>,
        <literal>ERROR</>, <literal>LOG</>, <literal>FATAL</>, and
        <literal>PANIC</>.  Each level includes all the levels that
        follow it.  The later the level, the fewer messages are sent
        to the log.  The default is <literal>NOTICE</>.  Note that
        <literal>LOG</> has a different rank here than in
        <varname>client_min_messages</>.
        Only superusers can change this setting.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-log-error-verbosity" xreflabel="log_error_verbosity">
      <term><varname>log_error_verbosity</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>log_error_verbosity</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Controls the amount of detail written in the server log for each
        message that is logged.  Valid values are <literal>TERSE</>,
        <literal>DEFAULT</>, and <literal>VERBOSE</>, each adding more
        fields to displayed messages.
        Only superusers can change this setting.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-log-min-error-statement" xreflabel="log_min_error_statement">
      <term><varname>log_min_error_statement</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>log_min_error_statement</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Controls whether or not the SQL statement that causes an error
2539 2540 2541 2542
        condition will be recorded in the server log.  The current
        SQL statement is included in the log entry for any message of
        the specified severity or higher.
        Valid values are <literal>DEBUG5</literal>,
2543 2544 2545 2546
        <literal>DEBUG4</literal>, <literal>DEBUG3</literal>,
        <literal>DEBUG2</literal>, <literal>DEBUG1</literal>,
        <literal>INFO</literal>, <literal>NOTICE</literal>,
        <literal>WARNING</literal>, <literal>ERROR</literal>,
2547
        <literal>LOG</literal>,
2548 2549
        <literal>FATAL</literal>, and <literal>PANIC</literal>.
        The default is <literal>ERROR</literal>, which means statements
2550
        causing errors, log messages, fatal errors, or panics will be logged.
2551 2552
        To effectively turn off logging of failing statements,
        set this parameter to <literal>PANIC</literal>.
2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2564
        Only superusers can change this setting.
       </para>
      </listitem>
     </varlistentry>
     
     <varlistentry id="guc-log-min-duration-statement" xreflabel="log_min_duration_statement">
      <term><varname>log_min_duration_statement</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>log_min_duration_statement</> configuration parameter</primary>
      </indexterm>
       <listitem>
        <para>
2565 2566 2567 2568
         Causes the duration of each completed statement to be logged
         if the statement ran for at least the specified number of
         milliseconds.  Setting this to zero prints all statement durations.
         Minus-one (the default) disables logging statement durations.
2569
         For example, if you set it to <literal>250ms</literal>
2570
         then all SQL statements that run 250ms or longer will be
2571 2572 2573
         logged.  Enabling this parameter can be helpful in tracking down
         unoptimized queries in your applications.
         Only superusers can change this setting.
2574
        </para>
2575 2576 2577 2578 2579 2580 2581 2582 2583 2584 2585 2586 2587 2588 2589 2590 2591 2592 2593 2594

        <para>
         For clients using extended query protocol, durations of the Parse,
         Bind, and Execute steps are logged independently.
        </para>

       <note>
        <para>
         When using this option together with
         <xref linkend="guc-log-statement">,
         the text of statements that are logged because of
         <varname>log_statement</> will not be repeated in the
         duration log message.
         If you are not using <application>syslog</>, it is recommended 
         that you log the PID or session ID using
         <xref linkend="guc-log-line-prefix">
         so that you can link the statement message to the later
         duration message using the process ID or session ID.
        </para>
       </note>
2595 2596 2597 2598 2599 2600 2601 2602 2603 2604
       </listitem>
      </varlistentry>

     <varlistentry id="guc-silent-mode" xreflabel="silent_mode">
      <term><varname>silent_mode</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>silent_mode</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
2605
        Runs the server silently. If this parameter is set, the server
2606
        will automatically run in background and any controlling
2607
        terminals are disassociated.
2608 2609 2610
        The server's standard output and standard error are redirected
        to <literal>/dev/null</>, so any messages sent to them will be lost.
        Unless <application>syslog</> logging is selected or
2611
        <varname>start_log_collector</> is enabled, using this parameter
2612
        is discouraged because it makes it impossible to see error messages.
2613
        This parameter can only be set at server start.
2614 2615 2616 2617 2618 2619
       </para>
      </listitem>
     </varlistentry>

     </variablelist>

2620 2621 2622 2623 2624 2625 2626
    <para>
     <xref linkend="runtime-config-severity-levels"> explains the message
     severity levels used by <productname>PostgreSQL</>.  If logging output
     is sent to <systemitem>syslog</systemitem> or Windows'
     <systemitem>eventlog</systemitem>, the severity levels are translated
     as shown in the table.
    </para>
2627

2628 2629 2630 2631 2632 2633 2634 2635 2636 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2682 2683 2684 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705
    <table id="runtime-config-severity-levels">
     <title>Message severity levels</title>
     <tgroup cols="4">
      <thead>
       <row>
        <entry>Severity</entry>
        <entry>Usage</entry>
        <entry><systemitem>syslog</></entry>
        <entry><systemitem>eventlog</></entry>
       </row>
      </thead>

      <tbody>
       <row>
        <entry><literal>DEBUG1..DEBUG5</></entry>
        <entry>Provides successively-more-detailed information for use by
         developers.</entry>
        <entry><literal>DEBUG</></entry>
        <entry><literal>INFORMATION</></entry>
       </row>

       <row>
        <entry><literal>INFO</></entry>
        <entry>Provides information implicitly requested by the user,
         e.g., output from <command>VACUUM VERBOSE</>.</entry>
        <entry><literal>INFO</></entry>
        <entry><literal>INFORMATION</></entry>
       </row>

       <row>
        <entry><literal>NOTICE</></entry>
        <entry>Provides information that might be helpful to users, e.g.,
         notice of truncation of long identifiers.</entry>
        <entry><literal>NOTICE</></entry>
        <entry><literal>INFORMATION</></entry>
       </row>

       <row>
        <entry><literal>WARNING</></entry>
        <entry>Provides warnings of likely problems, e.g., <command>COMMIT</>
         outside a transaction block.</entry>
        <entry><literal>NOTICE</></entry>
        <entry><literal>WARNING</></entry>
       </row>

       <row>
        <entry><literal>ERROR</></entry>
        <entry>Reports an error that caused the current command to
         abort.</entry>
        <entry><literal>WARNING</></entry>
        <entry><literal>ERROR</></entry>
       </row>

       <row>
        <entry><literal>LOG</></entry>
        <entry>Reports information of interest to administrators, e.g.,
         checkpoint activity.</entry>
        <entry><literal>INFO</></entry>
        <entry><literal>INFORMATION</></entry>
       </row>

       <row>
        <entry><literal>FATAL</></entry>
        <entry>Reports an error that caused the current session to
         abort.</entry>
        <entry><literal>ERR</></entry>
        <entry><literal>ERROR</></entry>
       </row>

       <row>
        <entry><literal>PANIC</></entry>
        <entry>Reports an error that caused all database sessions to abort.</entry>
        <entry><literal>CRIT</></entry>
        <entry><literal>ERROR</></entry>
       </row>
      </tbody>
     </tgroup>
    </table>
2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2723 2724 2725 2726 2727 2728 2729 2730 2731

    </sect2>
     <sect2 id="runtime-config-logging-what">
     <title>What To Log</title>

     <variablelist>

     <varlistentry>
      <term><varname>debug_print_parse</varname> (<type>boolean</type>)</term>
      <term><varname>debug_print_rewritten</varname> (<type>boolean</type>)</term>
      <term><varname>debug_print_plan</varname> (<type>boolean</type>)</term>
      <term><varname>debug_pretty_print</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>debug_print_parse</> configuration parameter</primary>
      </indexterm>
      <indexterm>
       <primary><varname>debug_print_rewritten</> configuration parameter</primary>
      </indexterm>
      <indexterm>
       <primary><varname>debug_print_plan</> configuration parameter</primary>
      </indexterm>
      <indexterm>
       <primary><varname>debug_pretty_print</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
2732
        These parameters enable various debugging output to be emitted.
2733 2734 2735 2736 2737 2738 2739 2740
        For each executed query, they print
        the resulting parse tree, the query rewriter output, or the
        execution plan.  <varname>debug_pretty_print</varname> indents
        these displays to produce a more readable but much longer
        output format.  <varname>client_min_messages</varname> or
        <varname>log_min_messages</varname> must be
        <literal>DEBUG1</literal> or lower to actually send this output
        to the client or the server log, respectively.
2741
        These parameters are off by default.
2742 2743 2744 2745
       </para>
      </listitem>
     </varlistentry>

2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762
     <varlistentry id="guc-log-checkpoints" xreflabel="log_checkpoints">
      <term><varname>log_checkpoints</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>log_checkpoints</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Causes checkpoints to be logged in the server log. Some
        statistics about each checkpoint are included in the log messages,
        including the number of buffers written and the time spent writing
        them.
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line. The default is off.
       </para>
      </listitem>
     </varlistentry>

2763 2764 2765 2766 2767 2768 2769
     <varlistentry id="guc-log-connections" xreflabel="log_connections">
      <term><varname>log_connections</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>log_connections</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
2770 2771
        Causes each attempted connection to the server to be logged,
        as well as successful completion of client authentication.
2772
        This parameter can only be set in the <filename>postgresql.conf</>
2773
        file or on the server command line.  The default is off.
2774
       </para>
2775 2776 2777 2778 2779 2780 2781 2782 2783

       <note>
        <para>
         Some client programs, like <application>psql</>, attempt 
         to connect twice while determining if a password is required, so 
         duplicate <quote>connection received</> messages do not
         necessarily indicate a problem.
        </para>
       </note>
2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796
      </listitem>
     </varlistentry>

     <varlistentry id="guc-log-disconnections" xreflabel="log_disconnections">
      <term><varname>log_disconnections</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>log_disconnections</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        This outputs a line in the server log similar to
        <varname>log_connections</varname> but at session termination,
        and includes the duration of the session.  This is off by
2797 2798 2799
        default.
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811
       </para>
      </listitem>
     </varlistentry>


     <varlistentry id="guc-log-duration" xreflabel="log_duration">
      <term><varname>log_duration</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>log_duration</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
2812 2813 2814
        Causes the duration of every completed statement to be logged.
        The default is <literal>off</>.
        Only superusers can change this setting.
2815
       </para>
2816

2817 2818 2819 2820
       <para>
        For clients using extended query protocol, durations of the Parse,
        Bind, and Execute steps are logged independently.
       </para>
2821 2822 2823

       <note>
        <para>
2824 2825 2826 2827 2828 2829 2830 2831 2832
         The difference between setting this option and setting
         <xref linkend="guc-log-min-duration-statement"> to zero is that
         exceeding <varname>log_min_duration_statement</> forces the text of
         the query to be logged, but this option doesn't.  Thus, if
         <varname>log_duration</> is <literal>on</> and
         <varname>log_min_duration_statement</> has a positive value, all
         durations are logged but the query text is included only for
         statements exceeding the threshold.  This behavior can be useful for
         gathering statistics in high-load installations.
2833 2834
        </para>
       </note>
2835 2836
      </listitem>
     </varlistentry>
2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853

     <varlistentry id="guc-log-hostname" xreflabel="log_hostname">
      <term><varname>log_hostname</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>log_hostname</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        By default, connection log messages only show the IP address of the
        connecting host. Turning on this parameter 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 parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
       </para>
      </listitem>
     </varlistentry>
2854 2855 2856 2857 2858 2859 2860 2861 2862
     
     <varlistentry id="guc-log-line-prefix" xreflabel="log_line_prefix">
      <term><varname>log_line_prefix</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>log_line_prefix</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
         This is a <function>printf</>-style string that is output at the
2863 2864 2865 2866
         beginning of each log line.
         <literal>%</> characters begin <quote>escape sequences</>
         that are replaced with status information as outlined below.
         Unrecognized escapes are ignored. Other
2867
         characters are copied straight to the log line. Some escapes are
2868
         only recognized by session processes, and do not apply to
2869
         background processes such as the main server process.
2870
         This parameter can only be set in the <filename>postgresql.conf</>
2871
         file or on the server command line. The default is an empty string.
2872 2873 2874 2875 2876 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899

         <informaltable>
          <tgroup cols="3">
           <thead>
            <row>
             <entry>Escape</entry>
             <entry>Effect</entry>
             <entry>Session only</entry>
             </row>
            </thead>
           <tbody>
            <row>
             <entry><literal>%u</literal></entry>
             <entry>User name</entry>
             <entry>yes</entry>
            </row>
            <row>
             <entry><literal>%d</literal></entry>
             <entry>Database name</entry>
             <entry>yes</entry>
            </row>
            <row>
             <entry><literal>%r</literal></entry>
             <entry>Remote host name or IP address, and remote port</entry>
             <entry>yes</entry>
            </row>
            <row>
             <entry><literal>%h</literal></entry>
2900
             <entry>Remote host name or IP address</entry>
2901 2902 2903 2904 2905 2906 2907 2908 2909
             <entry>yes</entry>
            </row>
            <row>
             <entry><literal>%p</literal></entry>
             <entry>Process ID</entry>
             <entry>no</entry>
            </row>
            <row>
             <entry><literal>%t</literal></entry>
2910
             <entry>Time stamp without milliseconds</entry>
2911 2912 2913 2914 2915 2916 2917 2918 2919
             <entry>no</entry>
            </row>
            <row>
             <entry><literal>%m</literal></entry>
             <entry>Time stamp with milliseconds</entry>
             <entry>no</entry>
            </row>
            <row>
             <entry><literal>%i</literal></entry>
2920
             <entry>Command tag: type of session's current command</entry>
2921 2922 2923 2924
             <entry>yes</entry>
            </row>
            <row>
             <entry><literal>%c</literal></entry>
2925
             <entry>Session ID: see below</entry>
2926
             <entry>no</entry>
2927 2928 2929 2930 2931 2932 2933 2934
            </row>
            <row>
             <entry><literal>%l</literal></entry>
             <entry>Number of the log line for each process, starting at 1</entry>
             <entry>no</entry>
            </row>
            <row>
             <entry><literal>%s</literal></entry>
2935
             <entry>Process start time stamp</entry>
2936
             <entry>no</entry>
2937
            </row>
2938 2939 2940 2941 2942
            <row>
             <entry><literal>%v</literal></entry>
             <entry>Virtual transaction ID (backendID/localXID)</entry>
             <entry>no</entry>
            </row>
2943 2944
            <row>
             <entry><literal>%x</literal></entry>
2945 2946
             <entry>Transaction ID (0 if none is assigned)</entry>
             <entry>no</entry>
2947 2948 2949
            </row>
            <row>
             <entry><literal>%q</literal></entry>
2950 2951 2952
             <entry>Produces no output, but tells non-session
             processes to stop at this point in the string; ignored by
             session processes</entry>
2953 2954 2955 2956 2957 2958 2959 2960 2961 2962
             <entry>no</entry>
            </row>
            <row>
             <entry><literal>%%</literal></entry>
             <entry>Literal <literal>%</></entry>
             <entry>no</entry>
            </row>
           </tbody>
          </tgroup>
         </informaltable>
2963 2964 2965

         The <literal>%c</> escape prints a quasi-unique session identifier,
         consisting of two 4-byte hexadecimal numbers (without leading zeros)
2966
         separated by a dot.  The numbers are the process start time and the
2967 2968
         process ID, so <literal>%c</> can also be used as a space saving way
         of printing those items.
2969
       </para>
2970 2971 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986

       <tip>
        <para>
         If you set a nonempty value for <varname>log_line_prefix</>,
         you should usually make its last character be a space, to provide
         visual separation from the rest of the log line.  A punctuation
         character could be used too.
        </para>
       </tip>

       <tip>
        <para>
         <application>Syslog</> produces its own 
         time stamp and process ID information, so you probably do not want to
         use those escapes if you are logging to <application>syslog</>.
        </para>
       </tip>
2987 2988 2989
      </listitem>
     </varlistentry>

2990 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004
     <varlistentry id="guc-log-lock-waits" xreflabel="log_lock_waits">
      <term><varname>log_lock_waits</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>log_lock_waits</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Controls whether a log message is produced when a session waits
        longer than <xref linkend="guc-deadlock-timeout"> to acquire a
        lock.  This is useful in determining if lock waits are causing
        poor performance.  The default is <literal>off</>.
       </para>
      </listitem>
     </varlistentry>

3005 3006 3007 3008 3009 3010 3011 3012 3013 3014
     <varlistentry id="guc-log-statement" xreflabel="log_statement">
      <term><varname>log_statement</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>log_statement</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Controls which SQL statements are logged. Valid values are
        <literal>none</>, <literal>ddl</>, <literal>mod</>, and
        <literal>all</>. <literal>ddl</> logs all data definition
3015 3016 3017 3018 3019 3020 3021 3022 3023 3024 3025 3026
        statements, such as <command>CREATE</>, <command>ALTER</>, and
        <command>DROP</> statements. <literal>mod</> logs all
        <literal>ddl</> statements, plus data-modifying statements
        such as <command>INSERT</>,
        <command>UPDATE</>, <command>DELETE</>, <command>TRUNCATE</>,
        and <command>COPY FROM</>.
        <command>PREPARE</>, <command>EXECUTE</>, and
        <command>EXPLAIN ANALYZE</> statements are also logged if their
        contained command is of an appropriate type.  For clients using
        extended query protocol, logging occurs when an Execute message
        is received, and values of the Bind parameters are included
        (with any embedded single-quote marks doubled).
3027
       </para>
3028

3029 3030 3031 3032 3033 3034 3035
       <para>
        The default is <literal>none</>. Only superusers can change this
        setting.
       </para>

       <note>
        <para>
3036 3037 3038 3039 3040 3041 3042
         Statements that contain simple syntax errors are not logged
         even by the <varname>log_statement</> = <literal>all</> setting,
         because the log message is emitted only after basic parsing has
         been done to determine the statement type.  In the case of extended
         query protocol, this setting likewise does not log statements that
         fail before the Execute phase (i.e., during parse analysis or
         planning).  Set <varname>log_min_error_statement</> to
3043
         <literal>ERROR</> (or lower) to log such statements.      
3044 3045 3046 3047 3048
        </para>
       </note>
      </listitem>
     </varlistentry>

3049 3050 3051 3052 3053 3054 3055 3056
     <varlistentry id="guc-log-temp-files" xreflabel="log_temp_files">
      <term><varname>log_temp_files</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>log_temp_files</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Controls whether temporary files are logged when deleted.
3057 3058
        Temporary files can be
        created for sorts, hashes, and temporary query results.
3059 3060
        A value of zero logs all temporary files, and positive
        values log only files whose size is equal or greater than
3061 3062
        the specified number of kilobytes.  The
        default is <literal>-1</>, which disables this logging.
3063 3064 3065 3066
       </para>
      </listitem>
     </varlistentry>

3067 3068 3069 3070 3071 3072 3073 3074 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085
     <varlistentry id="guc-log-timezone" xreflabel="log_timezone">
      <term><varname>log_timezone</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>log_timezone</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the time zone used for timestamps written in the log.
        Unlike <xref linkend="guc-timezone">, this value is cluster-wide,
        so that all sessions will report timestamps consistently.
        The default is <literal>unknown</>, which means to use whatever
        the system environment specifies as the time zone.  See <xref
        linkend="datatype-timezones"> for more information.
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
       </para>
      </listitem>
     </varlistentry>

3086
     </variablelist>
3087 3088
    </sect2>
     <sect2 id="runtime-config-logging-csvlog">
3089
     <title>Using CSV-Format Log Output</title>
3090 3091

       <para>
Bruce Momjian's avatar
Bruce Momjian committed
3092 3093
        Including <literal>csvlog</> in the <varname>log_destination</> list 
        provides a convenient way to import log files into a database table. 
3094 3095 3096 3097 3098 3099
        This option emits log lines in comma-separated-value format,
        with these columns: timestamp with milliseconds, username, database
        name, session id, host:port number, process id, per-process line
        number, command tag, session start time, transaction id, error
        severity, SQL state code, statement/error message.
        Here is a sample table definition for storing CSV-format log output:
3100 3101 3102 3103 3104
       </para>

<programlisting>
CREATE TABLE postgres_log
(
3105
  log_time timestamp with time zone,
3106 3107
  username text,
  database_name text,
3108
  sessionid text,
3109
  connection_from text,
3110 3111
  process_id integer,
  process_line_num bigint,
3112
  command_tag text,
3113 3114
  session_start_time timestamp with time zone,
  transaction_id bigint,
3115 3116 3117 3118 3119 3120 3121 3122 3123
  error_severity text,
  sql_state_code text,
  statement text,
  PRIMARY KEY (sessionid, process_line_num)
);
</programlisting>


       <para>
3124 3125
        To import a log file into this table, use the <command>COPY FROM</>
        command:
3126 3127 3128 3129 3130 3131 3132
       </para>

<programlisting>
COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
</programlisting>

       <para>
3133 3134
       There are a few things you need to do to simplify importing CSV log
       files easily and automatically:
3135 3136 3137 3138

       <orderedlist>
         <listitem>
           <para>
3139 3140 3141 3142 3143
            Set <varname>log_filename</varname> and
            <varname>log_rotation_age</> to provide a consistent,
            predictable naming scheme for your log files.  This lets you
            predict what the file name will be and know when an individual log
            file is complete and therefore ready to be imported.
3144 3145 3146 3147 3148 3149
         </para>
        </listitem>

        <listitem>
           <para>
            Set <varname>log_rotation_size</varname> to 0 to disable 
Bruce Momjian's avatar
Bruce Momjian committed
3150 3151
            size-based log rotation, as it makes the log filename difficult 
            to predict. 
3152 3153 3154 3155 3156
           </para>
        </listitem>

        <listitem>
          <para>
3157 3158
           Set <varname>log_truncate_on_rotation</varname> to <literal>on</> so
           that old log data isn't mixed with the new in the same file.
3159 3160 3161 3162 3163
          </para>
        </listitem>

        <listitem>
          <para>
3164 3165 3166 3167 3168 3169 3170 3171 3172 3173
           The table definition above includes a primary key specification.
           This is useful to protect against accidentally importing the same
           information twice.  The <command>COPY</> command commits all of the
           data it imports at one time, so any error will cause the entire
           import to fail.  If you import a partial log file and later import
           the file again when it is complete, the primary key violation will
           cause the import to fail.  Wait until the log is complete and
           closed before importing.  This procedure will also protect against
           accidentally importing a partial line that hasn't been completely
           written, which would also cause <command>COPY</> to fail.
3174 3175 3176 3177 3178
          </para>
        </listitem>
        </orderedlist>
      </para>

3179 3180 3181 3182
    </sect2>
   </sect1>

   <sect1 id="runtime-config-statistics">
3183
    <title>Run-Time Statistics</title>
3184 3185 3186

    <sect2 id="runtime-config-statistics-collector">
     <title>Query and Index Statistics Collector</title>
3187 3188

     <para>
3189
      These parameters control server-wide statistics collection features.
3190 3191 3192 3193 3194 3195
      When statistics collection is enabled, the data that is produced can be
      accessed via the <structname>pg_stat</structname> and
      <structname>pg_statio</structname> family of system views.
      Refer to <xref linkend="monitoring"> for more information.
     </para>

3196 3197
     <variablelist>

3198 3199
     <varlistentry id="guc-track-activities" xreflabel="track_activities">
      <term><varname>track_activities</varname> (<type>boolean</type>)</term>
3200
      <indexterm>
3201
       <primary><varname>track_activities</> configuration parameter</primary>
3202 3203 3204 3205 3206
      </indexterm>
      <listitem>
       <para>
        Enables the collection of information on the currently
        executing command of each session, along with the time at
3207
        which that command began execution. This parameter is on by
3208 3209 3210 3211 3212 3213 3214 3215 3216
        default. Note that even when enabled, this information is not
        visible to all users, only to superusers and the user owning
        the session being reported on; so it should not represent a
        security risk.
        Only superusers can change this setting.
       </para>
      </listitem>
     </varlistentry>

3217 3218
     <varlistentry id="guc-track-counts" xreflabel="track_counts">
      <term><varname>track_counts</varname> (<type>boolean</type>)</term>
3219
      <indexterm>
3220
       <primary><varname>track_counts</> configuration parameter</primary>
3221 3222 3223
      </indexterm>
      <listitem>
       <para>
3224 3225
        Enables collection of statistics on database activity.
        This parameter is on by default, because the autovacuum
3226
        daemon needs the collected information.
3227
        Only superusers can change this setting.
3228 3229 3230 3231
       </para>
      </listitem>
     </varlistentry>

3232 3233
     <varlistentry id="guc-update-process-title" xreflabel="update_process_title">
      <term><varname>update_process_title</varname> (<type>boolean</type>)</term>
3234
      <indexterm>
3235
       <primary><varname>update_process_title</> configuration parameter</primary>
3236 3237 3238
      </indexterm>
      <listitem>
       <para>
3239 3240 3241 3242 3243
        Enables updating of the process title every time a new SQL command
        is received by the server.  The process title is typically viewed
        by the <command>ps</> command,
        or in Windows by using the <application>Process Explorer</>.
        Only superusers can change this setting.
3244 3245 3246 3247 3248 3249 3250 3251 3252 3253 3254 3255 3256 3257 3258 3259 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280
       </para>
      </listitem>
     </varlistentry>

     </variablelist>
    </sect2>

    <sect2 id="runtime-config-statistics-monitor">
     <title>Statistics Monitoring</title>
     <variablelist>

     <varlistentry>
      <term><varname>log_statement_stats</varname> (<type>boolean</type>)</term>
      <term><varname>log_parser_stats</varname> (<type>boolean</type>)</term>
      <term><varname>log_planner_stats</varname> (<type>boolean</type>)</term>
      <term><varname>log_executor_stats</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>log_statement_stats</> configuration parameter</primary>
      </indexterm>
      <indexterm>
       <primary><varname>log_parser_stats</> configuration parameter</primary>
      </indexterm>
      <indexterm>
       <primary><varname>log_planner_stats</> configuration parameter</primary>
      </indexterm>
      <indexterm>
       <primary><varname>log_executor_stats</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        For each query, write performance statistics of the respective
        module to the server log. This is a crude profiling
        instrument.  <varname>log_statement_stats</varname> reports total
        statement statistics, while the others report per-module statistics.
        <varname>log_statement_stats</varname> cannot be enabled together with
        any of the per-module options.  All of these options are disabled by
        default.   Only superusers can change these settings.
3281 3282 3283 3284 3285
       </para>
      </listitem>
     </varlistentry>

     </variablelist>
3286

3287 3288 3289 3290 3291 3292
    </sect2>
   </sect1>

   <sect1 id="runtime-config-autovacuum">
    <title>Automatic Vacuuming</title>

3293 3294
    <indexterm>
     <primary>autovacuum</primary>
3295
     <secondary>configuration parameters</secondary>
3296 3297
    </indexterm>

3298
     <para>
3299
      These settings control the behavior of the <firstterm>autovacuum</>
3300
      feature.  Refer to <xref linkend="autovacuum"> for
3301
      more information.
3302 3303 3304 3305 3306 3307 3308 3309 3310 3311 3312
     </para>

    <variablelist>

     <varlistentry id="guc-autovacuum" xreflabel="autovacuum">
      <term><varname>autovacuum</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>autovacuum</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
3313
        Controls whether the server should run the
3314 3315 3316
        autovacuum launcher daemon.  This is on by default; however,
        <xref linkend="guc-track-counts"> must also be turned on for
        autovacuum to work.
3317 3318
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
3319
       </para>
3320 3321
       <para>
        Note that even when this parameter is disabled, the system
3322
        will launch autovacuum processes if necessary to
3323 3324 3325
        prevent transaction ID wraparound.  See <xref
        linkend="vacuum-for-wraparound"> for more information.
       </para>
3326 3327 3328
      </listitem>
     </varlistentry>

3329 3330
     <varlistentry id="guc-log-autovacuum-min-duration" xreflabel="log_autovacuum_min_duration">
      <term><varname>log_autovacuum_min_duration</varname> (<type>integer</type>)</term>
3331
      <indexterm>
3332
       <primary><varname>log_autovacuum_min_duration</> configuration parameter</primary>
3333 3334 3335
      </indexterm>
      <listitem>
       <para>
3336 3337 3338 3339 3340 3341 3342
        Causes each action executed by autovacuum to be logged if it ran for at
        least the specified number of milliseconds.  Setting this to zero logs
        all autovacuum actions. Minus-one (the default) disables logging
        autovacuum actions.  For example, if you set this to
        <literal>250ms</literal> then all automatic vacuums and analyzes that run
        250ms or longer will be logged.  Enabling this parameter can be helpful
        in tracking autovacuum activity.  This setting can only be set in
3343 3344 3345 3346 3347
        the <filename>postgresql.conf</> file or on the server command line.
       </para>
      </listitem>
     </varlistentry>

3348 3349
     <varlistentry id="guc-autovacuum-max-workers" xreflabel="autovacuum_max_workers">
      <term><varname>autovacuum_max_workers</varname> (<type>integer</type>)</term>
3350
      <indexterm>
3351
       <primary><varname>autovacuum_max_workers</> configuration parameter</primary>
3352 3353 3354
      </indexterm>
      <listitem>
       <para>
3355 3356 3357
        Specifies the maximum number of autovacuum processes (other than the
        autovacuum launcher) which may be running at any one time.  The default
        is three.  This parameter can only be set in
3358 3359 3360 3361 3362
        the <filename>postgresql.conf</> file or on the server command line.
       </para>
      </listitem>
     </varlistentry>

3363 3364 3365 3366 3367 3368 3369
     <varlistentry id="guc-autovacuum-naptime" xreflabel="autovacuum_naptime">
      <term><varname>autovacuum_naptime</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>autovacuum_naptime</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
3370 3371 3372
        Specifies the minimum delay between autovacuum runs on any given
        database.  In each round the daemon examines the
        database and issues <command>VACUUM</> and <command>ANALYZE</> commands
3373
        as needed for tables in that database.  The delay is measured
3374
        in seconds, and the default is one minute (<literal>1m</>).
3375 3376
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3389
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-autovacuum-vacuum-threshold" xreflabel="autovacuum_vacuum_threshold">
      <term><varname>autovacuum_vacuum_threshold</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>autovacuum_vacuum_threshold</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the minimum number of updated or deleted tuples needed
        to trigger a <command>VACUUM</> in any one table.
3390
        The default is 50 tuples.
3391 3392
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
3393 3394
        This setting can be overridden for individual tables by entries in
        <structname>pg_autovacuum</>.
3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-autovacuum-analyze-threshold" xreflabel="autovacuum_analyze_threshold">
      <term><varname>autovacuum_analyze_threshold</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>autovacuum_analyze_threshold</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the minimum number of inserted, updated or deleted tuples
        needed to trigger an <command>ANALYZE</> in any one table.
3408
        The default is 50 tuples.
3409 3410
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
3411 3412
        This setting can be overridden for individual tables by entries in
        <structname>pg_autovacuum</>.
3413 3414 3415 3416 3417 3418 3419 3420 3421 3422 3423 3424 3425 3426
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-autovacuum-vacuum-scale-factor" xreflabel="autovacuum_vacuum_scale_factor">
      <term><varname>autovacuum_vacuum_scale_factor</varname> (<type>floating point</type>)</term>
      <indexterm>
       <primary><varname>autovacuum_vacuum_scale_factor</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies a fraction of the table size to add to
        <varname>autovacuum_vacuum_threshold</varname>
        when deciding whether to trigger a <command>VACUUM</>.
3427
        The default is 0.2 (20% of table size).
3428 3429
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
3430 3431
        This setting can be overridden for individual tables by entries in
        <structname>pg_autovacuum</>.
3432 3433 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-autovacuum-analyze-scale-factor" xreflabel="autovacuum_analyze_scale_factor">
      <term><varname>autovacuum_analyze_scale_factor</varname> (<type>floating point</type>)</term>
      <indexterm>
       <primary><varname>autovacuum_analyze_scale_factor</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies a fraction of the table size to add to
        <varname>autovacuum_analyze_threshold</varname>
        when deciding whether to trigger an <command>ANALYZE</>.
3446
        The default is 0.1 (10% of table size).
3447 3448
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
3449 3450
        This setting can be overridden for individual tables by entries in
        <structname>pg_autovacuum</>.
3451 3452 3453 3454
       </para>
      </listitem>
     </varlistentry>

3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467
     <varlistentry id="guc-autovacuum-freeze-max-age" xreflabel="autovacuum_freeze_max_age">
      <term><varname>autovacuum_freeze_max_age</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>autovacuum_freeze_max_age</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the maximum age (in transactions) that a table's
        <structname>pg_class</>.<structfield>relfrozenxid</> field can
        attain before a <command>VACUUM</> operation is forced to prevent
        transaction ID wraparound within the table.  Note that the system
        will launch autovacuum processes to prevent wraparound even when
        autovacuum is otherwise disabled.
3468
        The default is 200 million transactions.
3469 3470 3471 3472 3473 3474 3475 3476
        This parameter can only be set at server start, but the setting
        can be reduced for individual tables by entries in
        <structname>pg_autovacuum</>.
        For more information see <xref linkend="vacuum-for-wraparound">.
       </para>
      </listitem>
     </varlistentry>

3477 3478 3479 3480 3481 3482 3483 3484
     <varlistentry id="guc-autovacuum-vacuum-cost-delay" xreflabel="autovacuum_vacuum_cost_delay">
      <term><varname>autovacuum_vacuum_cost_delay</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>autovacuum_vacuum_cost_delay</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the cost delay value that will be used in automatic
3485
        <command>VACUUM</> operations.  If <literal>-1</> is
3486
        specified, the regular
3487
        <xref linkend="guc-vacuum-cost-delay"> value will be used.
3488
        The default value is 20 milliseconds.
3489 3490
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504
        This setting can be overridden for individual tables by entries in
        <structname>pg_autovacuum</>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-autovacuum-vacuum-cost-limit" xreflabel="autovacuum_vacuum_cost_limit">
      <term><varname>autovacuum_vacuum_cost_limit</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>autovacuum_vacuum_cost_limit</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the cost limit value that will be used in automatic
3505
        <command>VACUUM</> operations.  If <literal>-1</> is specified (which is the
3506
        default), the regular
3507 3508 3509 3510
        <xref linkend="guc-vacuum-cost-limit"> value will be used.  Note that
        the value is distributed proportionally among the running autovacuum
        workers, if there is more than one, so that the sum of the limits of
        each worker never exceeds the limit on this variable.
3511 3512
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3539 3540 3541 3542 3543 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3558 3559
        This setting can be overridden for individual tables by entries in
        <structname>pg_autovacuum</>.
       </para>
      </listitem>
     </varlistentry>

    </variablelist>
   </sect1>

   <sect1 id="runtime-config-client">
    <title>Client Connection Defaults</title>

    <sect2 id="runtime-config-client-statement">
     <title>Statement Behavior</title>
     <variablelist>

     <varlistentry id="guc-search-path" xreflabel="search_path">
      <term><varname>search_path</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>search_path</> configuration parameter</primary>
      </indexterm>
      <indexterm><primary>path</><secondary>for schemas</></>
      <listitem>
       <para>
        This variable specifies the order in which schemas are searched
        when an object (table, data type, function, etc.) is referenced by a
        simple name with no schema component.  When there are objects of
        identical names in different schemas, the one found first
        in the search path is used.  An object that is not in any of the
        schemas in the search path can only be referenced by specifying
        its containing schema with a qualified (dotted) name.
       </para>

       <para>
        The value for <varname>search_path</varname> has to be a comma-separated
        list of schema names.  If one of the list items is
        the special value <literal>$user</literal>, then the schema
        having the name returned by <function>SESSION_USER</> is substituted, if there
        is such a schema.  (If not, <literal>$user</literal> is ignored.)
       </para>

       <para>
        The system catalog schema, <literal>pg_catalog</>, is always
        searched, whether it is mentioned in the path or not.  If it is
        mentioned in the path then it will be searched in the specified
        order.  If <literal>pg_catalog</> is not in the path then it will
        be searched <emphasis>before</> searching any of the path items.
3560 3561 3562 3563 3564 3565 3566 3567 3568 3569 3570
       </para>

       <para>
        Likewise, the current session's temporary-table schema,
        <literal>pg_temp_<replaceable>nnn</></>, is always searched if it
        exists.  It can be explicitly listed in the path by using the
        alias <literal>pg_temp</>.  If it is not listed in the path then
        it is searched first (before even <literal>pg_catalog</>).  However,
        the temporary schema is only searched for relation (table, view,
        sequence, etc) and data type names.  It will never be searched for
        function or operator names.
3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581
       </para>

       <para>
        When objects are created without specifying a particular target
        schema, they will be placed in the first schema listed
        in the search path.  An error is reported if the search path is
        empty.
       </para>

       <para>
        The default value for this parameter is
3582
        <literal>'"$user", public'</literal> (where the second part will be
3583 3584 3585 3586 3587 3588 3589 3590 3591 3592 3593 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3608 3609 3610 3611 3612 3613 3614 3615 3616 3617 3618 3619 3620 3621 3622 3623
        ignored if there is no schema named <literal>public</>).
        This supports shared use of a database (where no users
        have private schemas, and all share use of <literal>public</>),
        private per-user schemas, and combinations of these.  Other
        effects can be obtained by altering the default search path
        setting, either globally or per-user.
       </para>

       <para>
        The current effective value of the search path can be examined
        via the <acronym>SQL</acronym> function
        <function>current_schemas()</>.  This is not quite the same as
        examining the value of <varname>search_path</varname>, since
        <function>current_schemas()</> shows how the requests
        appearing in <varname>search_path</varname> were resolved.
       </para>

       <para>
        For more information on schema handling, see <xref linkend="ddl-schemas">.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-default-tablespace" xreflabel="default_tablespace">
      <term><varname>default_tablespace</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>default_tablespace</> configuration parameter</primary>
      </indexterm>
      <indexterm><primary>tablespace</><secondary>default</></>
      <listitem>
       <para>
        This variable specifies the default tablespace in which to create
        objects (tables and indexes) when a <command>CREATE</> command does
        not explicitly specify a tablespace.
       </para>

       <para>
        The value is either the name of a tablespace, or an empty string
        to specify using the default tablespace of the current database.
        If the value does not match the name of any existing tablespace,
        <productname>PostgreSQL</> will automatically use the default
3624 3625 3626 3627 3628 3629 3630 3631
        tablespace of the current database.  If a nondefault tablespace
        is specified, the user must have <literal>CREATE</> privilege
        for it, or creation attempts will fail.
       </para>

       <para>
        This variable is not used for temporary tables; for them,
        <xref linkend="guc-temp-tablespaces"> is consulted instead.
3632 3633 3634 3635 3636 3637 3638 3639 3640
       </para>

       <para>
        For more information on tablespaces,
        see <xref linkend="manage-ag-tablespaces">.
       </para>
      </listitem>
     </varlistentry>

3641 3642 3643 3644 3645 3646 3647 3648 3649 3650 3651 3652 3653 3654 3655 3656 3657 3658
     <varlistentry id="guc-temp-tablespaces" xreflabel="temp_tablespaces">
      <term><varname>temp_tablespaces</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>temp_tablespaces</> configuration parameter</primary>
      </indexterm>
      <indexterm><primary>tablespace</><secondary>temporary</></>
      <listitem>
       <para>
        This variable specifies tablespace(s) in which to create temporary
        objects (temp tables and indexes on temp tables) when a
        <command>CREATE</> command does not explicitly specify a tablespace.
        Temporary files for purposes such as sorting large data sets
        are also created in these tablespace(s).
       </para>

       <para>
        The value is a list of names of tablespaces.  When there is more than
        one name in the list, <productname>PostgreSQL</> chooses a random
3659 3660 3661 3662 3663 3664
        member of the list each time a temporary object is to be created;
        except that within a transaction, successively created temporary
        objects are placed in successive tablespaces from the list.
        If any element of the list is an empty string,
        <productname>PostgreSQL</> will automatically use the default
        tablespace of the current database instead.
3665 3666 3667
       </para>

       <para>
3668 3669 3670 3671 3672 3673 3674
        When <varname>temp_tablespaces</> is set interactively, specifying a
        nonexistent tablespace is an error, as is specifying a tablespace for
        which the user does not have <literal>CREATE</> privilege.  However,
        when using a previously set value, nonexistent tablespaces are
        ignored, as are tablespaces for which the user lacks
        <literal>CREATE</> privilege.  In particular, this rule applies when
        using a value set in <filename>postgresql.conf</>.
3675 3676 3677 3678 3679 3680 3681 3682
       </para>

       <para>
        See also <xref linkend="guc-default-tablespace">.
       </para>
      </listitem>
     </varlistentry>

3683 3684 3685 3686 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3702 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3713 3714 3715 3716 3717 3718 3719 3720 3721 3722 3723 3724 3725 3726 3727 3728 3729 3730 3731 3732 3733 3734 3735 3736 3737 3738 3739 3740 3741 3742 3743 3744 3745 3746 3747
     <varlistentry id="guc-check-function-bodies" xreflabel="check_function_bodies">
      <term><varname>check_function_bodies</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>check_function_bodies</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        This parameter is normally on. When set to <literal>off</>, it
        disables validation of the function body string during <xref
        linkend="sql-createfunction"
        endterm="sql-createfunction-title">. Disabling validation is
        occasionally useful to avoid problems such as forward references
        when restoring function definitions from a dump.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-default-transaction-isolation" xreflabel="default_transaction_isolation">
      <indexterm>
       <primary>transaction isolation level</primary>
      </indexterm>
      <indexterm>
       <primary><varname>default_transaction_isolation</> configuration parameter</primary>
      </indexterm>
      <term><varname>default_transaction_isolation</varname> (<type>string</type>)</term>
      <listitem>
       <para>
        Each SQL transaction has an isolation level, which can be
        either <quote>read uncommitted</quote>, <quote>read
        committed</quote>, <quote>repeatable read</quote>, or
        <quote>serializable</quote>.  This parameter controls the
        default isolation level of each new transaction. The default
        is <quote>read committed</quote>.
       </para>

       <para>
        Consult <xref linkend="mvcc"> and <xref
        linkend="sql-set-transaction"
        endterm="sql-set-transaction-title"> for more information.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-default-transaction-read-only" xreflabel="default_transaction_read_only">
      <indexterm>
       <primary>read-only transaction</primary>
      </indexterm>
      <indexterm>
       <primary><varname>default_transaction_read_only</> configuration parameter</primary>
      </indexterm>

      <term><varname>default_transaction_read_only</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
        A read-only SQL transaction cannot alter non-temporary tables.
        This parameter controls the default read-only status of each new
        transaction. The default is <literal>off</> (read/write).
       </para>

       <para>
        Consult <xref linkend="sql-set-transaction"
        endterm="sql-set-transaction-title"> for more information.
       </para>
      </listitem>
     </varlistentry>
3748

3749 3750 3751 3752 3753 3754 3755 3756
     <varlistentry id="guc-statement-timeout" xreflabel="statement_timeout">
      <term><varname>statement_timeout</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>statement_timeout</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Abort any statement that takes over the specified number of
3757 3758
        milliseconds, starting from the time the command arrives at the server
        from the client.  If <varname>log_min_error_statement</> is set to
3759 3760 3761
        <literal>ERROR</> or lower, the statement that timed out will also be
        logged.  A value of zero (the default) turns off the 
        limitation.
3762 3763 3764
       </para>
      </listitem>
     </varlistentry>
3765

3766 3767 3768 3769 3770 3771 3772
     <varlistentry id="guc-session-replication-role" xreflabel="session_replication_role">
      <term><varname>session_replication_role</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>session_replication_role</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
Bruce Momjian's avatar
Bruce Momjian committed
3773
        Controls the trigger and rule firing for the current session.
Neil Conway's avatar
Neil Conway committed
3774
        See <xref linkend="sql-altertable" endterm="sql-altertable-title"> for the different options to
Bruce Momjian's avatar
Bruce Momjian committed
3775 3776 3777 3778
        enable or disable triggers and rules. Setting the variable requires
        superuser privilege and can only be done before any query plans have
        been cached. Possible values are <literal>origin</>,
        <literal>replica</> and <literal>local</>.
3779 3780 3781 3782
       </para>
      </listitem>
     </varlistentry>

3783 3784 3785 3786 3787 3788 3789 3790 3791 3792
     <varlistentry id="guc-vacuum-freeze-min-age" xreflabel="vacuum_freeze_min_age">
      <term><varname>vacuum_freeze_min_age</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>vacuum_freeze_min_age</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Specifies the cutoff age (in transactions) that <command>VACUUM</>
        should use to decide whether to replace transaction IDs with
        <literal>FrozenXID</> while scanning a table.
3793 3794 3795 3796 3797 3798 3799
        The default is 100 million transactions.  Although
        users can set this value anywhere from zero to one billion,
        <command>VACUUM</> will silently limit the effective value to half
        the value of <xref linkend="guc-autovacuum-freeze-max-age">, so
        that there is not an unreasonably short time between forced
        autovacuums.  For more information see <xref
        linkend="vacuum-for-wraparound">.
3800 3801 3802
       </para>
      </listitem>
     </varlistentry>
3803

3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3817 3818 3819 3820 3821 3822 3823 3824 3825 3826 3827 3828 3829
     <varlistentry id="guc-xmlbinary" xreflabel="xmlbinary">
      <term><varname>xmlbinary</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>xmlbinary</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets how binary values are to be encoded in XML.  This applies
        for example when <type>bytea</type> values are converted to
        XML by the functions <function>xmlelement</function> or
        <function>xmlforest</function>.  Possible values are
        <literal>base64</literal> and <literal>hex</literal>, which
        are both defined in the XML Schema standard.  The default is
        <literal>base64</literal>.  For further information about
        XML-related functions, see <xref linkend="functions-xml">.
       </para>

       <para>
        The actual choice here is mostly a matter of taste,
        constrained only by possible restrictions in client
        applications.  Both methods support all possible values,
        although the hex encoding will be somewhat larger than the
        base64 encoding.
       </para>
      </listitem>
     </varlistentry>
3830

3831 3832 3833 3834 3835 3836 3837 3838 3839
     <varlistentry id="guc-xmloption" xreflabel="xmloption">
      <term><varname>xmloption</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>xmloption</> configuration parameter</primary>
      </indexterm>
      <indexterm>
       <primary><varname>SET XML OPTION</></primary>
      </indexterm>
      <indexterm>
3840
       <primary>XML option</primary>
3841 3842 3843 3844 3845 3846 3847 3848 3849 3850 3851 3852 3853 3854 3855 3856 3857 3858 3859 3860 3861
      </indexterm>
      <listitem>
       <para>
        Sets whether <literal>DOCUMENT</literal> or
        <literal>CONTENT</literal> is implicit when converting between
        XML and character string values.  See <xref
        linkend="datatype-xml"> for a description of this.  Valid
        values are <literal>DOCUMENT</literal> and
        <literal>CONTENT</literal>.  The default is
        <literal>CONTENT</literal>.
       </para>

       <para>
        According to the SQL standard, the command to set this option is
<synopsis>
SET XML OPTION { DOCUMENT | CONTENT };
</synopsis>
        This syntax is also available in PostgreSQL.
       </para>
      </listitem>
     </varlistentry>
3862

3863 3864 3865 3866 3867 3868 3869 3870 3871 3872 3873 3874 3875 3876 3877 3878 3879 3880 3881 3882 3883 3884 3885 3886 3887 3888
     </variablelist>
    </sect2>
     <sect2 id="runtime-config-client-format">
     <title>Locale and Formatting</title>

     <variablelist>

     <varlistentry id="guc-datestyle" xreflabel="DateStyle">
      <term><varname>DateStyle</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>DateStyle</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the display format for date and time values, as well as the
        rules for interpreting ambiguous date input values. For
        historical reasons, this variable contains two independent
        components: the output format specification (<literal>ISO</>,
        <literal>Postgres</>, <literal>SQL</>, or <literal>German</>)
        and the input/output specification for year/month/day ordering
        (<literal>DMY</>, <literal>MDY</>, or <literal>YMD</>). These
        can be set separately or together. The keywords <literal>Euro</>
        and <literal>European</> are synonyms for <literal>DMY</>; the
        keywords <literal>US</>, <literal>NonEuro</>, and
        <literal>NonEuropean</> are synonyms for <literal>MDY</>. See
        <xref linkend="datatype-datetime"> for more information. The
3889 3890 3891 3892
        built-in default is <literal>ISO, MDY</>, but
        <application>initdb</application> will initialize the
        configuration file with a setting that corresponds to the
        behavior of the chosen <varname>lc_time</varname> locale.
3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-timezone" xreflabel="timezone">
      <term><varname>timezone</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>timezone</> configuration parameter</primary>
      </indexterm>
      <indexterm><primary>time zone</></>
      <listitem>
       <para>
3905
        Sets the time zone for displaying and interpreting time stamps.
3906
        The default is <literal>unknown</>, which means to use whatever
3907
        the system environment specifies as the time zone.  See <xref
3908
        linkend="datatype-timezones"> for more
3909
        information.
3910 3911 3912 3913
       </para>
      </listitem>
     </varlistentry>

3914 3915
     <varlistentry id="guc-timezone-abbreviations" xreflabel="timezone_abbreviations">
      <term><varname>timezone_abbreviations</varname> (<type>string</type>)</term>
3916
      <indexterm>
3917
       <primary><varname>timezone_abbreviations</> configuration parameter</primary>
3918
      </indexterm>
3919
      <indexterm><primary>time zone names</></>
3920 3921
      <listitem>
       <para>
3922
        Sets the collection of time zone abbreviations that will be accepted
3923
        by the server for datetime input.  The default is <literal>'Default'</>,
3924 3925 3926 3927
        which is a collection that works in most of the world; there are
        also 'Australia' and 'India', and other collections can be defined
        for a particular installation.  See <xref
        linkend="datetime-appendix"> for more information.
3928 3929 3930 3931 3932 3933 3934 3935 3936 3937 3938 3939 3940 3941 3942 3943 3944 3945 3946 3947 3948 3949 3950 3951 3952 3953 3954 3955 3956 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3970 3971 3972 3973 3974 3975 3976 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3991 3992 3993
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-extra-float-digits" xreflabel="extra_float_digits">
      <indexterm>
       <primary>significant digits</primary>
      </indexterm>
      <indexterm>
       <primary>floating-point</primary>
       <secondary>display</secondary>
      </indexterm>
      <indexterm>
       <primary><varname>extra_float_digits</> configuration parameter</primary>
      </indexterm>

      <term><varname>extra_float_digits</varname> (<type>integer</type>)</term>
      <listitem>
       <para>
        This parameter adjusts the number of digits displayed for
        floating-point values, including <type>float4</>, <type>float8</>,
        and geometric data types.  The parameter value is added to the
        standard number of digits (<literal>FLT_DIG</> or <literal>DBL_DIG</>
        as appropriate).  The value can be set as high as 2, to include
        partially-significant digits; this is especially useful for dumping
        float data that needs to be restored exactly.  Or it can be set
        negative to suppress unwanted digits.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-client-encoding" xreflabel="client_encoding">
      <term><varname>client_encoding</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>client_encoding</> configuration parameter</primary>
      </indexterm>
      <indexterm><primary>character set</></>
      <listitem>
       <para>
        Sets the client-side encoding (character set).
        The default is to use the database encoding.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-lc-messages" xreflabel="lc_messages">
      <term><varname>lc_messages</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>lc_messages</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the language in which messages are displayed.  Acceptable
        values are system-dependent; see <xref linkend="locale"> for
        more information.  If this variable is set to the empty string
        (which is the default) then the value is inherited from the
        execution environment of the server in a system-dependent way.
       </para>

       <para>
        On some systems, this locale category does not exist.  Setting
        this variable will still work, but there will be no effect.
        Also, there is a chance that no translated messages for the
        desired language exist.  In that case you will continue to see
        the English messages.
       </para>
3994 3995 3996

       <para>
        Only superusers can change this setting, because it affects the
3997
        messages sent to the server log as well as to the client.
3998
       </para>
3999 4000 4001 4002 4003 4004 4005 4006 4007 4008 4009 4010 4011 4012 4013 4014 4015 4016 4017 4018 4019 4020 4021 4022 4023 4024 4025 4026 4027 4028 4029 4030 4031 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4043 4044 4045
      </listitem>
     </varlistentry>

     <varlistentry id="guc-lc-monetary" xreflabel="lc_monetary">
      <term><varname>lc_monetary</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>lc_monetary</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the locale to use for formatting monetary amounts, for
        example with the <function>to_char</function> family of
        functions.  Acceptable values are system-dependent; see <xref
        linkend="locale"> for more information.  If this variable is
        set to the empty string (which is the default) then the value
        is inherited from the execution environment of the server in a
        system-dependent way.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-lc-numeric" xreflabel="lc_numeric">
      <term><varname>lc_numeric</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>lc_numeric</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the locale to use for formatting numbers, for example
        with the <function>to_char</function> family of
        functions. Acceptable values are system-dependent; see <xref
        linkend="locale"> for more information.  If this variable is
        set to the empty string (which is the default) then the value
        is inherited from the execution environment of the server in a
        system-dependent way.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-lc-time" xreflabel="lc_time">
      <term><varname>lc_time</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>lc_time</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Sets the locale to use for formatting date and time values.
4046
        (Currently, this setting does nothing, but it might in the
4047 4048 4049 4050 4051 4052 4053 4054 4055
        future.)  Acceptable values are system-dependent; see <xref
        linkend="locale"> for more information.  If this variable is
        set to the empty string (which is the default) then the value
        is inherited from the execution environment of the server in a
        system-dependent way.
       </para>
      </listitem>
     </varlistentry>

4056 4057 4058 4059 4060 4061 4062 4063 4064 4065 4066 4067 4068 4069 4070 4071 4072 4073 4074 4075
     <varlistentry id="guc-default-text-search-config" xreflabel="default_text_search_config">
      <term><varname>default_text_search_config</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>default_text_search_config</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Selects the text search configuration that is used by those variants
        of the text search functions that do not have an explicit argument
        specifying the configuration.
        See <xref linkend="textsearch"> for further information.
        The built-in default is <literal>pg_catalog.simple</>, but
        <application>initdb</application> will initialize the
        configuration file with a setting that corresponds to the
        chosen <varname>lc_ctype</varname> locale, if a configuration
        matching that locale can be identified.
       </para>
      </listitem>
     </varlistentry>

4076 4077 4078 4079 4080 4081 4082 4083 4084 4085 4086 4087 4088 4089 4090 4091 4092 4093 4094 4095 4096 4097 4098 4099 4100 4101 4102 4103 4104 4105 4106 4107 4108 4109 4110 4111 4112 4113 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4130 4131 4132 4133 4134 4135 4136 4137 4138 4139 4140 4141 4142 4143 4144 4145 4146 4147 4148 4149
     </variablelist>

    </sect2>
     <sect2 id="runtime-config-client-other">
     <title>Other Defaults</title>

     <variablelist>

     <varlistentry id="guc-explain-pretty-print" xreflabel="explain_pretty_print">
      <term><varname>explain_pretty_print</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>explain_pretty_print</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Determines whether <command>EXPLAIN VERBOSE</> uses the
        indented or non-indented format for displaying detailed
        query-tree dumps. The default is <literal>on</>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-dynamic-library-path" xreflabel="dynamic_library_path">
      <term><varname>dynamic_library_path</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>dynamic_library_path</> configuration parameter</primary>
      </indexterm>
      <indexterm><primary>dynamic loading</></>
      <listitem>
       <para>
        If a dynamically loadable module needs to be opened and the
        file name specified in the <command>CREATE FUNCTION</command> or
        <command>LOAD</command> command
        does not have a directory component (i.e. the
        name does not contain a slash), the system will search this
        path for the required file.
       </para>

       <para>
        The value for <varname>dynamic_library_path</varname> has to be a
        list of absolute directory paths separated by colons (or semi-colons
        on Windows).  If a list element starts
        with the special string <literal>$libdir</literal>, the
        compiled-in <productname>PostgreSQL</productname> package
        library directory is substituted for <literal>$libdir</literal>. This
        is where the modules provided by the standard
        <productname>PostgreSQL</productname> distribution are installed.
        (Use <literal>pg_config --pkglibdir</literal> to find out the name of
        this directory.) For example:
<programlisting>
dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
</programlisting>
        or, in a Windows environment:
<programlisting>
dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'
</programlisting>
       </para>

       <para>
        The default value for this parameter is
        <literal>'$libdir'</literal>. If the value is set to an empty
        string, the automatic path search is turned off.
       </para>

       <para>
        This parameter can be changed at run time by superusers, but a
        setting done that way will only persist until the end of the
        client connection, so this method should be reserved for
        development purposes. The recommended way to set this parameter
        is in the <filename>postgresql.conf</filename> configuration
        file.
       </para>
      </listitem>
     </varlistentry>
4150 4151 4152 4153 4154 4155 4156 4157 4158 4159 4160 4161 4162

     <varlistentry id="guc-gin-fuzzy-search-limit" xreflabel="gin_fuzzy_search_limit">
      <term><varname>gin_fuzzy_search_limit</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>gin_fuzzy_search_limit</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Soft upper limit of the size of the set returned by GIN index. For more
        information see <xref linkend="gin-tips">.
       </para>
      </listitem>
     </varlistentry>
4163

4164 4165 4166 4167 4168 4169 4170 4171 4172 4173 4174 4175 4176 4177 4178 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4192 4193 4194 4195 4196 4197 4198 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211
     <varlistentry id="guc-local-preload-libraries" xreflabel="local_preload_libraries">
      <term><varname>local_preload_libraries</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>local_preload_libraries</> configuration parameter</primary>
      </indexterm>
      <indexterm>
       <primary><filename>$libdir/plugins</></primary>
      </indexterm>
      <listitem>
       <para>
        This variable specifies one or more shared libraries that are
        to be preloaded at connection start.  If more than one library
        is to be loaded, separate their names with commas.
        This parameter cannot be changed after the start of a particular
        session.
       </para>

       <para>
        Because this is not a superuser-only option, the libraries
        that can be loaded are restricted to those appearing in the
        <filename>plugins</> subdirectory of the installation's
        standard library directory.  (It is the database administrator's
        responsibility to ensure that only <quote>safe</> libraries
        are installed there.)  Entries in <varname>local_preload_libraries</>
        can specify this directory explicitly, for example
        <literal>$libdir/plugins/mylib</literal>, or just specify
        the library name &mdash; <literal>mylib</literal> would have
        the same effect as <literal>$libdir/plugins/mylib</literal>.
       </para>

       <para>
        There is no performance advantage to loading a library at session
        start rather than when it is first used.  Rather, the intent of
        this feature is to allow debugging or performance-measurement
        libraries to be loaded into specific sessions without an explicit
        <command>LOAD</> command being given.  For example, debugging could
        be enabled for all sessions under a given user name by setting
        this parameter with <command>ALTER USER SET</>.
       </para>

       <para>
        If a specified library is not found,
        the connection attempt will fail.
       </para>

       <para>
        Every  PostgreSQL-supported library has a <quote>magic
        block</> that is checked to guarantee compatibility.  
4212
        For this reason, non-PostgreSQL libraries cannot be
4213 4214 4215 4216
        loaded in this way.
       </para>
      </listitem>
     </varlistentry>
4217 4218 4219 4220 4221 4222 4223 4224 4225 4226 4227 4228 4229 4230 4231 4232 4233 4234 4235 4236 4237 4238 4239 4240 4241 4242 4243 4244 4245

     </variablelist>
    </sect2>
   </sect1>

   <sect1 id="runtime-config-locks">
    <title>Lock Management</title>

     <variablelist>

     <varlistentry id="guc-deadlock-timeout" xreflabel="deadlock_timeout">
      <indexterm>
       <primary>deadlock</primary>
       <secondary>timeout during</secondary>
      </indexterm>
      <indexterm>
       <primary>timeout</primary>
       <secondary>deadlock</secondary>
      </indexterm>
      <indexterm>
       <primary><varname>deadlock_timeout</> configuration parameter</primary>
      </indexterm>

      <term><varname>deadlock_timeout</varname> (<type>integer</type>)</term>
      <listitem>
       <para>
        This is the amount of time, in milliseconds, to wait on a lock
        before checking to see if there is a deadlock condition. The
        check for deadlock is relatively slow, so the server doesn't run
4246
        it every time it waits for a lock. We optimistically assume
4247 4248 4249 4250
        that deadlocks are not common in production applications and
        just wait on the lock for a while before starting the check for a
        deadlock. Increasing this value reduces the amount of time
        wasted in needless deadlock checks, but slows down reporting of
4251
        real deadlock errors. The default is one second (<literal>1s</>),
4252
        which is probably about the smallest value you would want in
4253
        practice. On a heavily loaded server you might want to raise it.
4254
        Ideally the setting should exceed your typical transaction time,
4255 4256 4257 4258 4259 4260 4261 4262 4263 4264
        so as to improve the odds that a lock will be released before
        the waiter decides to check for deadlock.
       </para>

       <para>
        When <xref linkend="guc-log-lock-waits"> is set,
        this parameter also determines the length of time to wait before
        a log message is issued about the lock wait.  If you are trying
        to investigate locking delays you might want to set a shorter than
        normal <varname>deadlock_timeout</varname>.
4265 4266 4267 4268 4269 4270 4271 4272 4273 4274 4275
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-max-locks-per-transaction" xreflabel="max_locks_per_transaction">
      <term><varname>max_locks_per_transaction</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>max_locks_per_transaction</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
4276 4277 4278 4279 4280 4281 4282 4283 4284 4285 4286 4287 4288 4289
        The shared lock table is created to track locks on
        <varname>max_locks_per_transaction</varname> * (<xref
        linkend="guc-max-connections"> + <xref
        linkend="guc-max-prepared-transactions">) objects (e.g.  tables);
        hence, no more than this many distinct objects can be locked at
        any one time.  This parameter controls the average number of object
        locks allocated for each transaction;  individual transactions
        can lock more objects as long as the locks of all transactions
        fit in the lock table.  This is <emphasis>not</> the number of
        rows that can be locked; that value is unlimited.  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 parameter can only be set at
        server start.
4290 4291 4292
       </para>

       <para>
4293
        Increasing this parameter might cause <productname>PostgreSQL</>
4294 4295 4296 4297 4298 4299 4300 4301 4302 4303 4304 4305 4306 4307 4308 4309
        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>

     </variablelist>
   </sect1>

   <sect1 id="runtime-config-compatible">
    <title>Version and Platform Compatibility</title>

    <sect2 id="runtime-config-compatible-version">
     <title>Previous PostgreSQL Versions</title>
4310

4311 4312 4313 4314 4315 4316 4317 4318 4319 4320 4321 4322 4323 4324 4325 4326 4327 4328 4329 4330 4331 4332 4333 4334 4335 4336 4337 4338 4339 4340 4341 4342 4343
     <variablelist>

     <varlistentry id="guc-add-missing-from" xreflabel="add_missing_from">
      <term><varname>add_missing_from</varname> (<type>boolean</type>)</term>
      <indexterm><primary>FROM</><secondary>missing</></>
      <indexterm>
       <primary><varname>add_missing_from</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        When on, tables that are referenced by a query will be
        automatically added to the <literal>FROM</> clause if not
        already present. This behavior does not comply with the SQL
        standard and many people dislike it because it can mask mistakes
        (such as referencing a table where you should have referenced
        its alias). The default is <literal>off</>. This variable can be
        enabled for compatibility with releases of
        <productname>PostgreSQL</> prior to 8.1, where this behavior was
        allowed by default.
       </para>

       <para>
        Note that even when this variable is enabled, a warning
        message will be emitted for each implicit <literal>FROM</>
        entry referenced by a query. Users are encouraged to update
        their applications to not rely on this behavior, by adding all
        tables referenced by a query to the query's <literal>FROM</>
        clause (or its <literal>USING</> clause in the case of
        <command>DELETE</>).
       </para>
      </listitem>
     </varlistentry>

4344 4345
     <varlistentry id="guc-array-nulls" xreflabel="array_nulls">
      <term><varname>array_nulls</varname> (<type>boolean</type>)</term>
4346
      <indexterm>
4347
       <primary><varname>array_nulls</> configuration parameter</primary>
4348 4349 4350
      </indexterm>
      <listitem>
       <para>
4351
        This controls whether the array input parser recognizes
Peter Eisentraut's avatar
Peter Eisentraut committed
4352
        unquoted <literal>NULL</> as specifying a null array element.
4353
        By default, this is <literal>on</>, allowing array values containing
Peter Eisentraut's avatar
Peter Eisentraut committed
4354 4355
        null values to be entered.  However, <productname>PostgreSQL</> versions
        before 8.2 did not support null values in arrays, and therefore would
4356 4357 4358 4359
        treat <literal>NULL</> as specifying a normal array element with
        the string value <quote>NULL</>.  For backwards compatibility with
        applications that require the old behavior, this variable can be
        turned <literal>off</>.
4360 4361 4362
       </para>

       <para>
Peter Eisentraut's avatar
Peter Eisentraut committed
4363
        Note that it is possible to create array values containing null values
4364
        even when this variable is <literal>off</>.
4365 4366 4367 4368
       </para>
      </listitem>
     </varlistentry>

4369 4370 4371 4372 4373 4374 4375 4376 4377 4378 4379 4380 4381 4382 4383 4384 4385 4386 4387 4388 4389 4390 4391 4392 4393 4394 4395 4396 4397 4398 4399 4400 4401 4402 4403 4404
     <varlistentry id="guc-backslash-quote" xreflabel="backslash_quote">
      <term><varname>backslash_quote</varname> (<type>string</type>)</term>
      <indexterm><primary>strings</><secondary>backslash quotes</></>
      <indexterm>
       <primary><varname>backslash_quote</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        This controls whether a quote mark can be represented by
        <literal>\'</> in a string literal.  The preferred, SQL-standard way
        to represent a quote mark is by doubling it (<literal>''</>) but
        <productname>PostgreSQL</> has historically also accepted
        <literal>\'</>. However, use of <literal>\'</> creates security risks
        because in some client character set encodings, there are multibyte
        characters in which the last byte is numerically equivalent to ASCII
        <literal>\</>.  If client-side code does escaping incorrectly then a
        SQL-injection attack is possible.  This risk can be prevented by
        making the server reject queries in which a quote mark appears to be
        escaped by a backslash.
        The allowed values of <varname>backslash_quote</> are
        <literal>on</> (allow <literal>\'</> always),
        <literal>off</> (reject always), and
        <literal>safe_encoding</> (allow only if client encoding does not
        allow ASCII <literal>\</> within a multibyte character).
        <literal>safe_encoding</> is the default setting.
       </para>

       <para>
        Note that in a standard-conforming string literal, <literal>\</> just
        means <literal>\</> anyway.  This parameter affects the handling of
        non-standard-conforming literals, including
        escape string syntax (<literal>E'...'</>).
       </para>
      </listitem>
     </varlistentry>

4405 4406 4407 4408 4409 4410 4411 4412 4413 4414 4415 4416 4417
     <varlistentry id="guc-default-with-oids" xreflabel="default_with_oids">
      <term><varname>default_with_oids</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>default_with_oids</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        This controls whether <command>CREATE TABLE</command> and
        <command>CREATE TABLE AS</command> include an OID column in
        newly-created tables, if neither <literal>WITH OIDS</literal>
        nor <literal>WITHOUT OIDS</literal> is specified. It also
        determines whether OIDs will be included in tables created by
        <command>SELECT INTO</command>. In <productname>PostgreSQL</>
4418
        8.1 <varname>default_with_oids</> is <literal>off</> by default; in
Neil Conway's avatar
Neil Conway committed
4419 4420
        prior versions of <productname>PostgreSQL</productname>, it
        was on by default.
4421 4422 4423 4424 4425 4426 4427 4428 4429 4430 4431 4432 4433 4434 4435
       </para>

       <para>
        The use of OIDs in user tables is considered deprecated, so
        most installations should leave this variable disabled.
        Applications that require OIDs for a particular table should
        specify <literal>WITH OIDS</literal> when creating the
        table. This variable can be enabled for compatibility with old
        applications that do not follow this behavior.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-escape-string-warning" xreflabel="escape_string_warning">
      <term><varname>escape_string_warning</varname> (<type>boolean</type>)</term>
Tom Lane's avatar
Tom Lane committed
4436
      <indexterm><primary>strings</><secondary>escape warning</></>
4437 4438 4439 4440 4441 4442 4443
      <indexterm>
       <primary><varname>escape_string_warning</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        When on, a warning is issued if a backslash (<literal>\</>)
        appears in an ordinary string literal (<literal>'...'</>
4444 4445
        syntax) and <varname>standard_conforming_strings</varname> is off.
        The default is <literal>on</>.
4446 4447
       </para>
       <para>
4448 4449 4450 4451 4452
        Applications that wish to use backslash as escape should be
        modified to use escape string syntax (<literal>E'...'</>),
        because the default behavior of ordinary strings will change
        in a future release for SQL compatibility.  This variable can
        be enabled to help detect applications that will break.
4453 4454 4455 4456
       </para>
      </listitem>
     </varlistentry>

4457 4458 4459 4460 4461 4462 4463 4464 4465 4466 4467
     <varlistentry id="guc-regex-flavor" xreflabel="regex_flavor">
      <term><varname>regex_flavor</varname> (<type>string</type>)</term>
      <indexterm><primary>regular expressions</></>
      <indexterm>
       <primary><varname>regex_flavor</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        The regular expression <quote>flavor</> can be set to
        <literal>advanced</>, <literal>extended</>, or <literal>basic</>.
        The default is <literal>advanced</>.  The <literal>extended</>
4468
        setting might be useful for exact backwards compatibility with
4469 4470 4471 4472 4473 4474 4475 4476 4477 4478 4479 4480 4481 4482
        pre-7.4 releases of <productname>PostgreSQL</>.  See
        <xref linkend="posix-syntax-details"> for details.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-sql-inheritance" xreflabel="sql_inheritance">
      <term><varname>sql_inheritance</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>sql_inheritance</> configuration parameter</primary>
      </indexterm>
      <indexterm><primary>inheritance</></>
      <listitem>
       <para>
4483 4484 4485 4486 4487
        This controls the inheritance semantics.  If turned <literal>off</>,
        subtables are not included by various commands by default; basically
        an implied <literal>ONLY</literal> key word.  This was added for 
        compatibility with releases prior to 7.1.  See
        <xref linkend="ddl-inherit"> for more information.
4488 4489 4490 4491
       </para>
      </listitem>
     </varlistentry>

4492 4493 4494 4495 4496 4497 4498 4499 4500 4501 4502 4503 4504 4505 4506 4507
     <varlistentry id="guc-standard-conforming-strings" xreflabel="standard_conforming_strings">
      <term><varname>standard_conforming_strings</varname> (<type>boolean</type>)</term>
      <indexterm><primary>strings</><secondary>standard conforming</></>
      <indexterm>
       <primary><varname>standard_conforming_strings</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        This controls whether ordinary string literals
        (<literal>'...'</>) treat backslashes literally, as specified in
        the SQL standard.
        The default is currently <literal>off</>, causing
        <productname>PostgreSQL</productname> to have its historical
        behavior of treating backslashes as escape characters.
        The default will change to <literal>on</> in a future release
        to improve compatibility with the standard.
4508
        Applications can check this
4509 4510 4511 4512 4513 4514 4515 4516 4517
        parameter to determine how string literals will be processed.
        The presence of this parameter can also be taken as an indication
        that the escape string syntax (<literal>E'...'</>) is supported.
        Escape string syntax should be used if an application desires
        backslashes to be treated as escape characters.
       </para>
      </listitem>
     </varlistentry>

4518 4519
     </variablelist>
    </sect2>
4520

4521 4522 4523 4524 4525 4526 4527 4528 4529 4530 4531 4532 4533 4534 4535 4536 4537 4538 4539
    <sect2 id="runtime-config-compatible-clients">
     <title>Platform and Client Compatibility</title>
     <variablelist>

     <varlistentry id="guc-transform-null-equals" xreflabel="transform_null_equals">
      <term><varname>transform_null_equals</varname> (<type>boolean</type>)</term>
      <indexterm><primary>IS NULL</></>
      <indexterm>
       <primary><varname>transform_null_equals</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        When on, expressions of the form <literal><replaceable>expr</> =
        NULL</literal> (or <literal>NULL =
        <replaceable>expr</></literal>) are treated as
        <literal><replaceable>expr</> IS NULL</literal>, that is, they
        return true if <replaceable>expr</> evaluates to the null value,
        and false otherwise. The correct SQL-spec-compliant behavior of
        <literal><replaceable>expr</> = NULL</literal> is to always
4540
        return null (unknown). Therefore this parameter defaults to
4541 4542 4543 4544 4545 4546 4547 4548 4549 4550 4551 4552 4553 4554 4555 4556 4557 4558 4559 4560 4561 4562 4563 4564 4565 4566 4567 4568 4569 4570 4571 4572 4573 4574 4575 4576 4577 4578 4579 4580 4581 4582 4583 4584
        <literal>off</>.
       </para>

       <para>
        However, filtered forms in <productname>Microsoft
        Access</productname> generate queries that appear to use
        <literal><replaceable>expr</> = NULL</literal> to test for
        null values, so if you use that interface to access the database you
        might want to turn this option on.  Since expressions of the
        form <literal><replaceable>expr</> = NULL</literal> always
        return the null value (using the correct interpretation) they are not
        very useful and do not appear often in normal applications, so
        this option does little harm in practice.  But new users are
        frequently confused about the semantics of expressions
        involving null values, so this option is not on by default.
       </para>

       <para>
        Note that this option only affects the exact form <literal>= NULL</>,
        not other comparison operators or other expressions
        that are computationally equivalent to some expression
        involving the equals operator (such as <literal>IN</literal>).
        Thus, this option is not a general fix for bad programming.
       </para>

       <para>
        Refer to <xref linkend="functions-comparison"> for related information.
       </para>
      </listitem>
     </varlistentry>

     </variablelist>
    </sect2>
   </sect1>

   <sect1 id="runtime-config-preset">
    <title>Preset Options</title>

    <para>
     The following <quote>parameters</> are read-only, and are determined
     when <productname>PostgreSQL</productname> is compiled or when it is
     installed. As such, they have been excluded from the sample
     <filename>postgresql.conf</> file.  These options report
     various aspects of <productname>PostgreSQL</productname> behavior
4585
     that might be of interest to certain applications, particularly
4586 4587 4588 4589 4590 4591 4592 4593 4594 4595 4596 4597 4598 4599 4600 4601 4602 4603 4604 4605 4606 4607 4608 4609 4610 4611 4612 4613 4614 4615 4616 4617 4618 4619 4620 4621 4622 4623 4624 4625 4626 4627 4628 4629 4630 4631 4632 4633 4634 4635 4636 4637 4638 4639 4640 4641 4642 4643 4644 4645 4646 4647 4648 4649 4650 4651 4652 4653 4654 4655 4656 4657 4658 4659 4660 4661 4662
     administrative front-ends.
    </para>

    <variablelist>

     <varlistentry id="guc-block-size" xreflabel="block_size">
      <term><varname>block_size</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>block_size</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Reports the size of a disk block.  It is determined by the value
        of <literal>BLCKSZ</> when building the server. The default
        value is 8192 bytes.  The meaning of some configuration
        variables (such as <xref linkend="guc-shared-buffers">) is
        influenced by <varname>block_size</varname>. See <xref
        linkend="runtime-config-resource"> for information.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-integer-datetimes" xreflabel="integer_datetimes">
      <term><varname>integer_datetimes</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>integer_datetimes</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Reports whether <productname>PostgreSQL</productname> was built
        with support for 64-bit-integer dates and times.  It is set by
        configuring with <literal>--enable-integer-datetimes</literal>
        when building <productname>PostgreSQL</productname>.  The
        default value is <literal>off</literal>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-lc-collate" xreflabel="lc_collate">
      <term><varname>lc_collate</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>lc_collate</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Reports the locale in which sorting of textual data is done.
        See <xref linkend="locale"> for more information.
        The value is determined when the database cluster is initialized.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-lc-ctype" xreflabel="lc_ctype">
      <term><varname>lc_ctype</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>lc_ctype</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Reports the locale that determines character classifications.
        See <xref linkend="locale"> for more information.
        The value is determined when the database cluster is initialized.
        Ordinarily this will be the same as <varname>lc_collate</varname>,
        but for special applications it might be set differently.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-max-function-args" xreflabel="max_function_args">
      <term><varname>max_function_args</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>max_function_args</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Reports the maximum number of function arguments. It is determined by
        the value of <literal>FUNC_MAX_ARGS</> when building the server. The
4663
        default value is 100 arguments.
4664 4665 4666 4667 4668 4669 4670 4671 4672 4673 4674 4675 4676 4677 4678
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-max-identifier-length" xreflabel="max_identifier_length">
      <term><varname>max_identifier_length</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>max_identifier_length</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Reports the maximum identifier length. It is determined as one
        less than the value of <literal>NAMEDATALEN</> when building
        the server. The default value of <literal>NAMEDATALEN</> is
        64; therefore the default
4679
        <varname>max_identifier_length</varname> is 63 bytes.
4680 4681 4682 4683 4684 4685 4686 4687 4688 4689 4690 4691 4692
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-max-index-keys" xreflabel="max_index_keys">
      <term><varname>max_index_keys</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>max_index_keys</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Reports the maximum number of index keys. It is determined by
        the value of <literal>INDEX_MAX_KEYS</> when building the server. The
4693
        default value is 32 keys.
4694 4695 4696 4697 4698 4699 4700 4701 4702 4703 4704 4705 4706 4707 4708 4709 4710 4711 4712 4713 4714 4715 4716 4717 4718 4719 4720 4721 4722 4723 4724 4725 4726
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-server-encoding" xreflabel="server_encoding">
      <term><varname>server_encoding</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>server_encoding</> configuration parameter</primary>
      </indexterm>
      <indexterm><primary>character set</></>
      <listitem>
       <para>
        Reports the database encoding (character set).
        It is determined when the database is created.  Ordinarily,
        clients need only be concerned with the value of <xref
        linkend="guc-client-encoding">.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-server-version" xreflabel="server_version">
      <term><varname>server_version</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>server_version</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Reports the version number of the server. It is determined by the
        value of <literal>PG_VERSION</> when building the server.
       </para>
      </listitem>
     </varlistentry>

4727 4728 4729 4730 4731 4732 4733 4734 4735 4736 4737 4738 4739
     <varlistentry id="guc-server-version-num" xreflabel="server_version_num">
      <term><varname>server_version_num</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>server_version_num</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Reports the version number of the server as an integer. It is determined 
        by the value of <literal>PG_VERSION_NUM</> when building the server.
       </para>
      </listitem>
     </varlistentry>

4740 4741 4742 4743 4744 4745 4746
    </variablelist>
   </sect1>

   <sect1 id="runtime-config-custom">
    <title>Customized Options</title>

    <para>
4747
     This feature was designed to allow parameters not normally known to
4748 4749 4750 4751 4752 4753 4754 4755 4756 4757 4758 4759 4760 4761 4762 4763 4764 4765 4766 4767 4768
     <productname>PostgreSQL</productname> to be added by add-on modules
     (such as procedural languages).  This allows add-on modules to be
     configured in the standard ways.
    </para>

    <variablelist>

     <varlistentry id="guc-custom-variable-classes" xreflabel="custom_variable_classes">
      <term><varname>custom_variable_classes</varname> (<type>string</type>)</term>
      <indexterm>
       <primary><varname>custom_variable_classes</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        This variable specifies one or several class names to be used for
        custom variables, in the form of a comma-separated list. A custom
        variable is a variable not normally known
        to <productname>PostgreSQL</productname> proper but used by some
        add-on module.  Such variables must have names consisting of a class
        name, a dot, and a variable name.  <varname>custom_variable_classes</>
        specifies all the class names in use in a particular installation.
4769 4770
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
4771 4772 4773 4774 4775 4776 4777 4778 4779 4780 4781 4782 4783 4784 4785 4786 4787 4788 4789 4790 4791 4792 4793 4794 4795 4796 4797 4798 4799 4800 4801 4802 4803 4804 4805 4806 4807 4808
       </para>

      </listitem>
     </varlistentry>
    </variablelist>

    <para>
     The difficulty with setting custom variables in
     <filename>postgresql.conf</> is that the file must be read before add-on
     modules have been loaded, and so custom variables would ordinarily be
     rejected as unknown.  When <varname>custom_variable_classes</> is set,
     the server will accept definitions of arbitrary variables within each
     specified class.  These variables will be treated as placeholders and
     will have no function until the module that defines them is loaded. When a
     module for a specific class is loaded, it will add the proper variable
     definitions for its class name, convert any placeholder
     values according to those definitions, and issue warnings for any
     placeholders of its class that remain (which presumably would be
     misspelled configuration variables).
    </para>

    <para>
     Here is an example of what <filename>postgresql.conf</> might contain
     when using custom variables:

<programlisting>
custom_variable_classes = 'plr,plperl'
plr.path = '/usr/lib/R'
plperl.use_strict = true
plruby.use_strict = true        # generates error: unknown class name
</programlisting>
    </para>
   </sect1>

   <sect1 id="runtime-config-developer">
    <title>Developer Options</title>

    <para>
4809
     The following parameters are intended for work on the
4810 4811 4812 4813 4814
     <productname>PostgreSQL</productname> source, and in some cases
     to assist with recovery of severely damaged databases.  There
     should be no reason to use them in a production database setup.
     As such, they have been excluded from the sample
     <filename>postgresql.conf</> file.  Note that many of these
4815
     parameters require special source compilation flags to work at all.
4816 4817 4818
    </para>

    <variablelist>
4819 4820 4821 4822 4823 4824 4825
     <varlistentry id="guc-allow-system-table-mods" xreflabel="allow_system_table_mods">
      <term><varname>allow_system_table_mods</varname> (<type>boolean</type>)</term>
      <indexterm>
        <primary><varname>allow_system_table_mods</varname> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
4826
        Allows modification of the structure of system tables.
4827
        This is used by <command>initdb</command>.
4828
        This parameter can only be set at server start.
4829 4830 4831 4832
       </para>
      </listitem>
     </varlistentry>

4833 4834 4835 4836 4837 4838 4839 4840 4841 4842
     <varlistentry id="guc-debug-assertions" xreflabel="debug_assertions">
      <term><varname>debug_assertions</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>debug_assertions</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Turns on various assertion checks. This is a debugging aid. If
        you are experiencing strange problems or crashes you might want
        to turn this on, as it might expose programming mistakes. To use
4843
        this parameter, the macro <symbol>USE_ASSERT_CHECKING</symbol>
4844 4845 4846 4847 4848 4849 4850 4851 4852 4853
        must be defined when <productname>PostgreSQL</productname> is
        built (accomplished by the <command>configure</command> option
        <option>--enable-cassert</option>). Note that
        <varname>debug_assertions</varname> defaults to <literal>on</>
        if <productname>PostgreSQL</productname> has been built with
        assertions enabled.
       </para>
      </listitem>
     </varlistentry>

4854 4855 4856 4857 4858 4859 4860 4861 4862 4863
     <varlistentry id="guc-ignore-system-indexes" xreflabel="ignore_system_indexes">
      <term><varname>ignore_system_indexes</varname> (<type>boolean</type>)</term>
      <indexterm>
        <primary><varname>ignore_system_indexes</varname> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Ignore system indexes when reading system tables (but still
        update the indexes when modifying the tables).  This is useful
        when recovering from damaged system indexes.
4864
        This parameter cannot be changed after session start.
4865 4866 4867 4868 4869 4870 4871 4872 4873 4874 4875 4876 4877 4878 4879
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-post-auth-delay" xreflabel="post_auth_delay">
      <term><varname>post_auth_delay</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>post_auth_delay</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        If nonzero, a delay of this many seconds occurs when a new
        server process is started, after it conducts the
        authentication procedure.  This is intended to give an
        opportunity to attach to the server process with a debugger.
4880
        This parameter cannot be changed after session start.
4881 4882 4883 4884
       </para>
      </listitem>
     </varlistentry>

4885 4886 4887 4888 4889 4890 4891
     <varlistentry id="guc-pre-auth-delay" xreflabel="pre_auth_delay">
      <term><varname>pre_auth_delay</varname> (<type>integer</type>)</term>
      <indexterm>
       <primary><varname>pre_auth_delay</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
4892 4893 4894 4895 4896
        If nonzero, a delay of this many seconds occurs just after a
        new server process is forked, before it conducts the
        authentication procedure.  This is intended to give an
        opportunity to attach to the server process with a debugger to
        trace down misbehavior in authentication.
4897 4898
        This parameter can only be set in the <filename>postgresql.conf</>
        file or on the server command line.
4899 4900 4901 4902 4903 4904 4905 4906 4907 4908 4909 4910 4911 4912 4913 4914 4915 4916 4917 4918 4919
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-trace-notify" xreflabel="trace_notify">
      <term><varname>trace_notify</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>trace_notify</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Generates a great amount of debugging output for the
        <command>LISTEN</command> and <command>NOTIFY</command>
        commands.  <xref linkend="guc-client-min-messages"> or
        <xref linkend="guc-log-min-messages"> must be
        <literal>DEBUG1</literal> or lower to send this output to the
        client or server log, respectively.
       </para>
      </listitem>
     </varlistentry>

4920 4921 4922 4923 4924 4925 4926 4927
     <varlistentry id="guc-trace-sort" xreflabel="trace_sort">
      <term><varname>trace_sort</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>trace_sort</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        If on, emit information about resource usage during sort operations.
4928
        This parameter is only available if the <symbol>TRACE_SORT</symbol> macro
4929 4930 4931 4932 4933 4934
        was defined when <productname>PostgreSQL</productname> was compiled.
        (However, <symbol>TRACE_SORT</symbol> is currently defined by default.)
       </para>
      </listitem>
     </varlistentry>

4935 4936 4937 4938 4939 4940 4941 4942 4943 4944 4945 4946 4947 4948 4949 4950 4951 4952 4953 4954 4955 4956
     <varlistentry>
      <term><varname>trace_locks</varname> (<type>boolean</type>)</term>
      <term><varname>trace_lwlocks</varname> (<type>boolean</type>)</term>
      <term><varname>trace_userlocks</varname> (<type>boolean</type>)</term>
      <term><varname>trace_lock_oidmin</varname> (<type>boolean</type>)</term>
      <term><varname>trace_lock_table</varname> (<type>boolean</type>)</term>
      <term><varname>debug_deadlocks</varname> (<type>boolean</type>)</term>
      <term><varname>log_btree_build_stats</varname> (<type>boolean</type>)</term>
      <listitem>
       <para>
        Various other code tracing and debugging options.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-wal-debug" xreflabel="wal_debug">
      <term><varname>wal_debug</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>wal_debug</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
4957
        If on, emit WAL-related debugging output. This parameter is
4958 4959 4960 4961 4962 4963 4964 4965 4966 4967 4968 4969 4970 4971 4972 4973 4974 4975 4976 4977
        only available if the <symbol>WAL_DEBUG</symbol> macro was
        defined when <productname>PostgreSQL</productname> was
        compiled.
       </para>
      </listitem>
     </varlistentry>

    <varlistentry id="guc-zero-damaged-pages" xreflabel="zero_damaged_pages">
      <term><varname>zero_damaged_pages</varname> (<type>boolean</type>)</term>
      <indexterm>
       <primary><varname>zero_damaged_pages</> configuration parameter</primary>
      </indexterm>
      <listitem>
       <para>
        Detection of a damaged page header normally causes
        <productname>PostgreSQL</> to report an error, aborting the current
        command.  Setting <varname>zero_damaged_pages</> to on causes
        the system to instead report a warning, zero out the damaged page,
        and continue processing.  This behavior <emphasis>will destroy data</>,
        namely all the rows on the damaged page.  But it allows you to get
4978
        past the error and retrieve rows from any undamaged pages that might
4979 4980 4981 4982 4983 4984 4985 4986 4987 4988 4989 4990 4991 4992 4993
        be present in the table.  So it is useful for recovering data if
        corruption has occurred due to hardware or software error.  You should
        generally not set this on until you have given up hope of recovering
        data from the damaged page(s) of a table.  The
        default setting is <literal>off</>, and it can only be changed
        by a superuser.
       </para>
      </listitem>
     </varlistentry>
   </variablelist>
  </sect1>
  <sect1 id="runtime-config-short">
   <title>Short Options</title>

   <para>
4994 4995 4996 4997 4998 4999
    For convenience there are also single letter command-line option
    switches available for some parameters.  They are described in
    <xref linkend="runtime-config-short-table">.  Some of these
    options exist for historical reasons, and their presence as a
    single-letter option does not necessarily indicate an endorsement
    to use the option heavily.
5000 5001 5002 5003 5004 5005 5006 5007 5008 5009 5010 5011 5012
   </para>

    <table id="runtime-config-short-table">
     <title>Short option key</title>
     <tgroup cols="2">
      <thead>
       <row>
        <entry>Short option</entry>
        <entry>Equivalent</entry>
       </row>
      </thead>

      <tbody>
5013 5014 5015 5016
       <row>
        <entry><option>-A <replaceable>x</replaceable></option></entry>
        <entry><literal>debug_assertions = <replaceable>x</replaceable></></entry>
       </row>
5017 5018 5019 5020 5021 5022 5023 5024
       <row>
        <entry><option>-B <replaceable>x</replaceable></option></entry>
        <entry><literal>shared_buffers = <replaceable>x</replaceable></></entry>
       </row>
       <row>
        <entry><option>-d <replaceable>x</replaceable></option></entry>
        <entry><literal>log_min_messages = DEBUG<replaceable>x</replaceable></></entry>
       </row>
5025 5026 5027 5028 5029 5030 5031 5032 5033 5034 5035 5036 5037 5038 5039 5040 5041 5042 5043 5044
       <row>
        <entry><option>-e</option></entry>
        <entry><literal>datestyle = euro</></entry>
       </row>
       <row>
        <entry>
          <option>-fb</option>, <option>-fh</option>, <option>-fi</option>,
          <option>-fm</option>, <option>-fn</option>,
          <option>-fs</option>, <option>-ft</option>
         </entry>
         <entry>
          <literal>enable_bitmapscan = off</>,
          <literal>enable_hashjoin = off</>,
          <literal>enable_indexscan = off</>,
          <literal>enable_mergejoin = off</>,
          <literal>enable_nestloop = off</>,
          <literal>enable_seqscan = off</>,
          <literal>enable_tidscan = off</>
         </entry>
       </row>
5045 5046 5047 5048 5049 5050 5051 5052 5053 5054 5055 5056 5057 5058 5059 5060 5061 5062 5063 5064 5065 5066 5067 5068
       <row>
        <entry><option>-F</option></entry>
        <entry><literal>fsync = off</></entry>
       </row>
       <row>
        <entry><option>-h <replaceable>x</replaceable></option></entry>
        <entry><literal>listen_addresses = <replaceable>x</replaceable></></entry>
       </row>
       <row>
        <entry><option>-i</option></entry>
        <entry><literal>listen_addresses = '*'</></entry>
       </row>
       <row>
        <entry><option>-k <replaceable>x</replaceable></option></entry>
        <entry><literal>unix_socket_directory = <replaceable>x</replaceable></></entry>
       </row>
       <row>
        <entry><option>-l</option></entry>
        <entry><literal>ssl = on</></entry>
       </row>
       <row>
        <entry><option>-N <replaceable>x</replaceable></option></entry>
        <entry><literal>max_connections = <replaceable>x</replaceable></></entry>
       </row>
5069 5070 5071 5072
       <row>
        <entry><option>-O</option></entry>
        <entry><literal>allow_system_table_mods = on</></entry>
       </row>
5073 5074 5075 5076 5077
       <row>
        <entry><option>-p <replaceable>x</replaceable></option></entry>
        <entry><literal>port = <replaceable>x</replaceable></></entry>
       </row>
       <row>
5078 5079
        <entry><option>-P</option></entry>
        <entry><literal>ignore_system_indexes = on</></entry>
5080 5081
       </row>
       <row>
5082
        <entry><option>-s</option></entry>
5083 5084 5085
        <entry><literal>log_statement_stats = on</></entry>
       </row>
       <row>
5086
        <entry><option>-S <replaceable>x</replaceable></option></entry>
5087 5088 5089
        <entry><literal>work_mem = <replaceable>x</replaceable></></entry>
       </row>
       <row>
5090
        <entry><option>-tpa</option>, <option>-tpl</option>, <option>-te</option></entry>
5091 5092 5093 5094
        <entry><literal>log_parser_stats = on</>,
        <literal>log_planner_stats = on</>, 
        <literal>log_executor_stats = on</></entry>
       </row>
5095 5096 5097 5098
       <row>
        <entry><option>-W <replaceable>x</replaceable></option></entry>
        <entry><literal>post_auth_delay = <replaceable>x</replaceable></></entry>
       </row>
5099 5100 5101 5102 5103 5104
      </tbody>
     </tgroup>
    </table>

  </sect1>
</chapter>