2 $Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.25 2000/09/29 20:21:34 petere Exp $
6 <Title>Server Runtime Environment</Title>
9 This chapter discusses how to set up and run the database server
10 and the interactions with the operating system.
13 <sect1 id="postgres-user">
14 <title>The Postgres user account</title>
17 As with any other server daemon that is connected to the world at
18 large, it is advisable to run Postgres under a separate user
19 account. This user account should only own the data itself that is
20 being managed by the server, and should not be shared with other
21 daemons. (Thus, using the user <quote>nobody</quote> is a bad
22 idea.) It is not advisable to install the executables as owned by
23 this user account because that runs the risk of user-defined
24 functions gone astray or any other exploits compromising the
29 To add a user account to your system, look for a command
30 <command>useradd</command> or <command>adduser</command>. The user
31 name <quote>postgres</quote> is often used but by no means
36 <sect1 id="creating-cluster">
37 <title>Creating a database cluster</title>
40 Before you can do anything, you must initialize a database storage
41 area on disk. We call this a <firstterm>database
42 cluster</firstterm>. (<acronym>SQL</acronym> speaks of a catalog
43 cluster instead.) A database cluster is a collection of databases
44 that will be accessible through a single instance of a running
45 database server. After initialization, a database cluster will
46 contain one database named <literal>template1</literal>. As the
47 name suggests, this will be used as a template for any subsequently
48 created database; it should not be used for actual work.
52 In file system terms, a database cluster will be a single directory
53 under which all data will be stored. We call this the
54 <firstterm>data directory</firstterm> or <firstterm>data
55 area</firstterm>. It is completely up to you where you choose to
56 store your data, there is no default, although locations such as
57 <filename>/usr/local/pgsql/data</filename> or
58 <filename>/var/lib/pgsql/data</filename> are popular. To initialize
59 a database cluster, use the command <command>initdb</command>,
60 which is installed with <productname>PostgreSQL</productname>. The
61 desired file system location of your database system is indicated
62 by the <option>-D</option> option, for example
64 > <userinput>initdb -D /usr/local/pgsql/data</userinput>
66 Note that you must execute this command while being logged in to
67 the Postgres user account, which is described in the previous
73 As an alternative to the <option>-D</option> option, you can set
74 the environment variable <envar>PGDATA</envar>.
79 <command>initdb</command> will attempt to create the directory you
80 specify if it does not already exist. It is likely that it won't
81 have the permission to do so (if you followed our advice and
82 created an unprivileged account). In that case you can create the
83 directory yourself (as root) and transfer ownership of it or grant
84 write access to it. Here is how this might work:
86 root# <userinput>mkdir /usr/local/pgsql/data</userinput>
87 root# <userinput>chown postgres /usr/local/pgsql/data</userinput>
88 root# <userinput>su postgres</userinput>
89 postgres> <userinput>initdb -D /usr/local/pgsql/data</userinput>
94 <command>initdb</command> will refuse to run if the data directory
95 looks like it belongs to an already initialized installation.
99 Because the data directory contains all the data stored in the
100 database it is essential that it be well secured from unauthorized
101 access. <command>initdb</command> therefore revokes access
102 permissions from everyone but the Postgres user account.
106 <sect1 id="postmaster-start">
107 <title>Starting the database server</title>
110 Before anyone can access the database you must start the database
111 server. The database server is called
112 <firstterm>postmaster</firstterm>.
113 The postmaster must know where to find the data it is supposed
114 to work on. This is done with the <option>-D</option> option. Thus,
115 the simplest way to start the server is, for example,
117 > <userinput>postmaster -D /usr/local/pgsql/data</userinput>
119 which will leave the server running in the foreground. This must
120 again be done while logged in to the Postgres user account. Without
121 a <option>-D</option>, the server will try to use the data
122 directory in the environment variable <envar>PGDATA</envar>; if
123 neither of these works it will fail.
127 To start the <application>postmaster</application> in the
128 background, use the usual shell syntax:
130 > <userinput>postmaster -D /usr/local/pgsql/data > logfile 1>&2 &</userinput>
132 It is an extremely good idea to keep the server output around
133 somewhere, as indicated here. It will help both for auditing
134 purposes and to diagnose problems.
138 The postmaster also takes a number of other command line options.
139 For more information see the reference page and below under runtime
140 configuration. In particular, in order for the postmaster to accept
141 TCP/IP connections (rather than just Unix domain socket ones), you
142 must also specify the <option>-i</option> option.
146 Normally, you will want to start the database server when the
147 computer boots up. This is not required; the
148 <productname>PostgreSQL</productname> server can be run
149 successfully from non-privileged accounts without root
154 Different systems have different conventions for starting up
155 daemons at boot time, so you are advised to familiarize yourself
156 with them. Many systems have a file
157 <filename>/etc/rc.local</filename> or
158 <filename>/etc/rc.d/rc.local</filename> which is almost certainly
159 no bad place to put such a command. Whatever you do, postmaster
160 must be run by the <productname>Postgres</productname> user account
161 <emphasis>and not by root</emphasis> or any other user. Therefore
162 you probably always want to form your command lines along the lines
163 of <literal>su -c '...' postgres</literal>, for example:
165 nohup su -c 'postmaster -D /usr/local/pgsql/data > server.log 2>&1' postgres &
167 (using the program <application>nohup</application> to prevent the
168 server from dying when you log out).
172 Here are a few more operating system specific suggestions.
177 Edit the file <filename>rc.local</filename> on
178 <productname>NetBSD</productname> or file
179 <filename>rc2.d</filename> on <productname>Solaris</productname> to contain the
180 following single line:
182 su postgres -c "/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data"
189 On <productname>FreeBSD</productname> edit
190 <filename>/usr/local/etc/rc.d/pgsql.sh</filename> to contain the
191 following lines and make it <literal>chmod 755</literal> and
192 <literal>chown root:bin</literal>.
195 [ -x /usr/local/pgsql/bin/postmaster ] && {
196 su -l pgsql -c 'exec /usr/local/pgsql/bin/postmaster
197 -D/usr/local/pgsql/data
198 -S -o -F > /usr/local/pgsql/errlog' &
202 You may put the line breaks as shown above. The shell is smart
203 enough to keep parsing beyond end-of-line if there is an
204 expression unfinished. The exec saves one layer of shell under
205 the postmaster process so the parent is init.
211 On <productname>RedHat Linux</productname> add a file
212 <filename>/etc/rc.d/init.d/postgres.init</filename>
213 which is based on the example in <filename>contrib/linux/</filename>.
214 Then make a softlink to this file from
215 <filename>/etc/rc.d/rc5.d/S98postgres.init</filename>.
222 While the <application>postmaster</application> is running, it's
223 PID is in the file <filename>postmaster.pid</filename> in the data
224 directory. This is used as in interlock against multiple running
225 postmaster on the same data directory and can also be used for
226 shutting down the postmaster.
230 The shell script wrapper <application>pg_ctl</application> that
231 comes with <productname>Postgres</productname> can also be used to
232 control starting (and stopping!) of the database server in
236 <sect2 id="postmaster-start-failures">
237 <title>Server Start-up Failures</title>
240 There are several common reasons for the postmaster to fail to
241 start up. Check the postmaster's log file, or start it by hand
242 (without redirecting standard output or standard error) to see
243 what complaint messages appear. Some of the possible error
244 messages are reasonably self-explanatory, but here are some that
250 FATAL: StreamServerPort: bind() failed: Address already in use
251 Is another postmaster already running on that port?
253 This usually means just what it suggests: you accidentally
254 started a second postmaster on the same port where one is already
255 running. However, if the kernel error message is not
256 <computeroutput>Address already in use</computeroutput> or some
257 variant of that wording, there may be a different problem. For
258 example, trying to start a postmaster on a reserved port number
259 may draw something like
261 > <userinput>postmaster -i -p 666</userinput>
262 FATAL: StreamServerPort: bind() failed: Permission denied
263 Is another postmaster already running on that port?
270 IpcMemoryCreate: shmget(key=5440001, size=83918612, 01600) failed: Invalid argument
271 FATAL 1: ShmemCreate: cannot create region
273 probably means that your kernel's limit on the size of shared
274 memory areas is smaller than the buffer area that Postgres is
275 trying to create (83918612 bytes in this example). Or it could
276 mean that you don't have System-V-style shared memory support
277 configured into your kernel at all. As a temporary workaround,
278 you can try starting the postmaster with a smaller-than-normal
279 number of buffers (<option>-B</option> switch). You will
280 eventually want to reconfigure your kernel to increase the
281 allowed shared memory size, however. You may see this message
282 when trying to start multiple postmasters on the same machine, if
283 their total space requests exceed the kernel limit.
289 IpcSemaphoreCreate: semget(key=5440026, num=16, 01600) failed: No space left on device
291 does <emphasis>not</emphasis> mean that you've run out of disk
292 space; it means that your kernel's limit on the number of System
293 V semaphores is smaller than the number
294 <productname>Postgres</productname> wants to create. As above,
295 you may be able to work around the problem by starting the
296 postmaster with a reduced number of backend processes
297 (<option>-N</option> switch), but you'll eventually want to
298 increase the kernel limit.
302 If you get an <quote>illegal system call</> error, then it is likely that
303 shared memory or semaphores are not supported at all in your kernel. In
304 that case your only option is to re-configure the kernel to turn on these
309 Details about configuring System V IPC facilities are given in
310 <xref linkend="sysvipc">.
314 <sect2 id="client-connection-problems">
315 <title>Client Connection Problems</title>
318 Although the possible error conditions on the client side are
319 both virtually infinite and application dependent, a few of them
320 might be directly related to how the server was started up.
321 Conditions other than those shown below should be documented with
322 the respective client application.
327 connectDB() -- connect() failed: Connection refused
328 Is the postmaster running (with -i) at 'server.joe.com' and accepting connections on TCP/IP port '5432'?
330 This is the generic <quote>I couldn't find a server to talk
331 to</quote> failure. It looks like the above when TCP/IP
332 communication is attempted. A common mistake is to forget the
333 <option>-i</option> to the postmaster to allow TCP/IP
338 Alternatively, you'll get this when attempting
339 Unix-socket communication to a local postmaster:
341 connectDB() -- connect() failed: No such file or directory
342 Is the postmaster running at 'localhost' and accepting connections on Unix socket '5432'?
347 The last line is useful in verifying that the client is trying to
348 connect where it is supposed to. If there is in fact no
349 postmaster running there, the kernel error message will typically
350 be either <computeroutput>Connection refused</computeroutput> or
351 <computeroutput>No such file or directory</computeroutput>, as
352 illustrated. (It is particularly important to realize that
353 <computeroutput>Connection refused</computeroutput> in this
354 context does <emphasis>not</emphasis> mean that the postmaster
355 got your connection request and rejected it -- that case will
356 produce a different message, as shown in <xref
357 linkend="client-authentication-problems">.) Other error messages
358 such as <computeroutput>Connection timed out</computeroutput> may
359 indicate more fundamental problems, like lack of network
365 <sect1 id="runtime-config">
366 <Title>Run-time configuration</Title>
369 There are a lot of configuration parameters that affect the
370 behavior of the database system in some way or other. Here we
371 describe how to set them and the following subsections will
372 discuss each of them.
376 All parameter names are case-insensitive. Every parameter takes a
377 value of one of the four types boolean, integer, floating point,
378 string as described below. Boolean values are
379 <literal>ON</literal>, <literal>OFF</literal>,
380 <literal>TRUE</literal>, <literal>FALSE</literal>,
381 <literal>YES</literal>, <literal>NO</literal>,
382 <literal>1</literal>, <literal>0</literal> (case-insensitive) or
383 any non-ambiguous prefix of these.
387 One way to set these options is to create a file
388 <filename>postgresql.conf</filename> in the data directory (e.g.,
389 <filename>/usr/local/pgsql/data</filename>). An example of what
390 this file could look like is:
393 log_connections = yes
396 As you see, options are one per line. The equal sign between name
397 and value is optional. White space is insignificant, blank lines
398 are ignored. Hash marks (<quote>#</quote>) introduce comments
403 The configuration file is reread whenever the postmaster receives
404 a SIGHUP signal. This signal is also propagated to all running
405 backend processes, so that running sessions get the new default.
406 Alternatively, you can send the signal to only one backend process
411 A second way to set these configuration parameters is to give them
412 as a command line option to the postmaster, such as
414 postmaster --log-connections=yes --syslog=2
416 which would have the same effect as the previous example.
420 Occasionally it is also useful to give a command line option to
421 one particular backend session only. The environment variable
422 <envar>PGOPTIONS</envar> can be used for this purpose on the
425 env PGOPTIONS='--geqo=off' psql
427 (This works for any client application, not just
428 <application>psql</application>.) Note that this won't work for
429 options that are necessarily fixed once the server is started,
430 such as the port number.
434 Finally, some options can be changed in individual SQL sessions
435 with the <command>SET</command> command, for example
437 => <userinput>SET ENABLE_SEQSCAN TO OFF;</userinput>
439 See the SQL command language reference for details on the syntax.
442 <sect2 id="runtime-config-optimizer">
443 <title>Planner and Optimizer Tuning</title>
448 <term>CPU_INDEX_TUPLE_COST (<type>floating point</type>)</term>
451 Sets the query optimizer's estimate of the cost of processing
452 each index tuple during an index scan. This is measured as a
453 fraction of the cost of a sequential page fetch.
459 <term>CPU_OPERATOR_COST (<type>floating point</type>)</term>
462 Sets the optimizer's estimate of the cost of processing each
463 operator in a WHERE clause. This is measured as a fraction of
464 the cost of a sequential page fetch.
470 <term>CPU_TUPLE_COST (<type>floating point</type>)</term>
473 Sets the query optimizer's estimate of the cost of processing
474 each tuple during a query. This is measured as a fraction of
475 the cost of a sequential page fetch.
481 <term>EFFECTIVE_CACHE_SIZE (<type>floating point</type>)</term>
484 Sets the optimizer's assumption about the effective size of
485 the disk cache (that is, the portion of the kernel's disk
486 cache that will be used for
487 <productname>Postgres</productname> data files). This is
488 measured in disk pages, which are normally 8kB apiece.
494 <term>ENABLE_HASHJOIN (<type>boolean</type>)</term>
497 Enables or disables the query planner's use of hash-join plan
498 types. The default is on. This is mostly useful to debug the
505 <term>ENABLE_INDEXSCAN (<type>boolean</type>)</term>
508 Enables or disables the query planner's use of index scan plan
509 types. The default is on. This is mostly useful to debug the
516 <term>ENABLE_MERGEJOIN (<type>boolean</type>)</term>
519 Enables or disables the query planner's use of merge-join plan
520 types. The default is on. This is mostly useful to debug the
527 <term>ENABLE_NESTLOOP (<type>boolean</type>)</term>
530 Enables or disables the query planner's use of nested-loop
531 join plans. It's not possible to suppress nested-loop joins
532 entirely, but turning this variable off discourages the
533 planner from using one if there is any other method available.
534 The default is on. This is mostly useful to debug the query
541 <term>ENABLE_SEQSCAN (<type>boolean</type>)</term>
544 Enables or disables the query planner's use of sequential scan
545 plan types. It's not possible to suppress sequential scans
546 entirely, but turning this variable off discourages the
547 planner from using one if there is any other method available.
548 The default is on. This is mostly useful to debug the query
555 <term>ENABLE_SORT (<type>boolean</type>)</term>
558 Enables or disables the query planner's use of explicit sort
559 steps. It's not possible to suppress explicit sorts entirely,
560 but turning this variable off discourages the planner from
561 using one if there is any other method available. The default
562 is on. This is mostly useful to debug the query planner.
568 <term>ENABLE_TIDSCAN (<type>boolean</type>)</term>
571 Enables or disables the query planner's use of TID scan plan
572 types. The default is on. This is mostly useful to debug the
579 <term>GEQO (<type>boolean</type>)</term>
582 Enables or disables genetic query optimization, which is an
583 algorithm that attempts to do query planning without
584 exhaustive search. This is on by default. See also the various
585 other GEQO_ settings.
591 <term>GEQO_EFFORT (<type>integer</type>)</term>
592 <term>GEQO_GENERATIONS (<type>integer</type>)</term>
593 <term>GEQO_POOL_SIZE (<type>integer</type>)</term>
594 <term>GEQO_RANDOM_SEED (<type>integer</type>)</term>
595 <term>GEQO_SELECTION_BIAS (<type>floating point</type>)</term>
598 Various tuning parameters for the genetic query optimization
599 algorithm: The pool size is the number of individuals in one
600 population. Valid values are between 128 and 1024. If it is
601 set to 0 (the default) a pool size of 2^(QS+1), where QS
602 is the number of relations in the query, is taken. The effort
603 is used to calculate a default for generations. Valid values
604 are between 1 and 80, 40 being the default. Generations
605 specifies the number of iterations in the algorithm. The
606 number must be a positive integer. If 0 is specified then
607 Effort * Log2(PoolSize) is used. The run time of the algorithm
608 is roughly proportional to the sum of pool size and
609 generations. The selection bias is the selective pressure
610 within the population. Values can be from 1.50 to 2.00; the
611 latter is the default. The random seed can be set to get
612 reproduceable results from the algorithm. If it is set to -1
613 then the algorithm behaves non-deterministically.
619 <term>GEQO_RELS (<type>integer</type>)</term>
622 Only use genetic query optimization for queries with at least
623 this many relations involved. The default is 11. For less
624 relations it is probably more efficient to use the
625 deterministic, exhaustive planner.
631 <term>KSQO (<type>boolean</type>)</term>
634 The <firstterm>Key Set Query Optimizer</firstterm>
635 (<abbrev>KSQO</abbrev>) causes the query planner to convert
636 queries whose WHERE clause contains many OR'ed AND clauses
637 (such as <literal>WHERE (a=1 AND b=2) OR (a=2 AND b=3)
638 ...</literal>) into a UNION query. This method can be faster
639 than the default implementation, but it doesn't necessarily
640 give exactly the same results, since UNION implicitly adds a
641 SELECT DISTINCT clause to eliminate identical output rows.
642 KSQO is commonly used when working with products like
643 <productname>Microsoft Access</productname>, which tend to
644 generate queries of this form.
648 The KSQO algorithm used to be absolutely essential for queries
649 with many OR'ed AND clauses, but in
650 <productname>Postgres</productname> 7.0 and later the standard
651 planner handles these queries fairly successfully. Hence the
658 <term>RANDOM_PAGE_COST (<type>floating point</type>)</term>
661 Sets the query optimizer's estimate of the cost of a
662 nonsequentially fetched disk page. This is measured as a
663 multiple of the cost of a sequential page fetch.
672 Unfortunately, there is no well-defined method of determining
673 ideal values for the family of <quote>COST</quote> variables that
674 were just described. You are encouraged to experiment and share
682 <title>Logging and Debugging</title>
687 <term>DEBUG_ASSERTIONS (<type>boolean</type>)</term>
690 Turns on various assertion checks. This is a debugging aid. If
691 you are experiencing strange problems or crashes you might
692 want to turn this on, as it might expose programming mistakes.
693 To use this option, the macro <literal>USE_ASSERT_CHECKING</literal>
694 must be defined when Postgres is built (see the configure option
695 <literal>--enable-cassert</literal>). Note that
696 <literal>DEBUG_ASSERTIONS</literal> defaults to ON if Postgres
697 has been built this way.
703 <term>DEBUG_LEVEL (<type>integer</type>)</term>
706 The higher this value is set, the more
707 <quote>debugging</quote> output of various sorts is generated
708 in the server log during operation. This option is 0 by
709 default, which means no debugging output. Values up to about 4
710 currently make sense.
716 <term>DEBUG_PRINT_PARSE (<type>boolean</type>)</term>
717 <term>DEBUG_PRINT_PLAN (<type>boolean</type>)</term>
718 <term>DEBUG_PRINT_REWRITTEN (<type>boolean</type>)</term>
719 <term>DEBUG_PRINT_QUERY (<type>boolean</type>)</term>
720 <term>DEBUG_PRETTY_PRINT (<type>boolean</type>)</term>
723 For any executed query, prints either the query, the parse
724 tree, the execution plan, or the query rewriter output to the
725 server log. <option>DEBUG_PRETTY_PRINT</option> selects are
726 nicer but longer output format.
732 <term>HOSTLOOKUP (<type>boolean</type>)</term>
735 By default, connection logs only show the IP address of the
736 connecting host. If you want it to show the host name you can
737 turn this on, but depending on your host name resolution setup
738 it might impose a non-negligible performance penalty. This
739 option can only be set at server start.
745 <term>LOG_CONNECTIONS (<type>boolean</type>)</term>
748 Prints a line informing about each successful connection to
749 the server log. This is off by default, although it is
750 probably very useful. This option can only be set at server
757 <term>LOG_PID (<type>boolean</type>)</term>
760 Prefixes each server log message with the process id of the
761 backend process. This is useful to sort out which messages
762 pertain to which connection. The default is off.
768 <term>LOG_TIMESTAMP (<type>boolean</type>)</term>
771 Prefixes each server log message with a timestamp. The default
778 <term>SHOW_QUERY_STATS (<type>boolean</type>)</term>
779 <term>SHOW_PARSER_STATS (<type>boolean</type>)</term>
780 <term>SHOW_PLANNER_STATS (<type>boolean</type>)</term>
781 <term>SHOW_EXECUTOR_STATS (<type>boolean</type>)</term>
784 For each query, write performance statistics of the respective
785 module to the server log. This is a crude profiling
792 <term>SHOWPORTNUMBER (<type>boolean</type>)</term>
795 Shows the port number of the connecting host in the connection
796 log messages. You could trace back the port number to find out
797 what user initiated the connection. Other than that it's
798 pretty useless and therefore off by default. This option can
799 only be set at server start.
805 <term>SYSLOG (<type>integer</type>)</term>
808 <productname>Postgres</productname> allows the use of
809 <application>syslog</application> for logging. If this option
810 is set to 1, messages go both to syslog and the standard
811 output. A setting of 2 sends output only to syslog. (Some
812 messages will still go to the standard output/error.) The
813 default is 0, which means syslog is off. This option must be
817 To use syslog, the build of
818 <productname>Postgres</productname> must be configured with
819 the <option>--enable-syslog</option> option.
825 <term>TRACE_NOTIFY (<type>boolean</type>)</term>
828 Generates a great amount of debugging output for the
829 <command>LISTEN</command> and <command>NOTIFY</command>
838 <sect2 id="runtime-config-general">
839 <title>General operation</title>
844 <term>DEADLOCK_TIMEOUT (<type>integer</type>)</term>
847 This is the amount of time, in milliseconds, to wait on a lock
848 before checking to see if there is a deadlock condition or not.
849 The check for deadlock is relatively slow, so we don't want to
850 run it every time we wait for a lock. We (optimistically?)
851 assume that deadlocks are not common in production applications,
852 and just wait on the lock for awhile before starting to ask
853 questions about whether it can ever get unlocked.
854 Increasing this value reduces the amount of time wasted in
855 needless deadlock checks, but slows down reporting of real deadlock
856 errors. The default is 1000 (i.e., one second), which is probably
857 about the smallest value you would want in practice. On a heavily
858 loaded server you might want to raise it. Ideally the setting
859 should exceed your typical transaction time, so as to improve the
860 odds that the lock will be released before the waiter decides to
862 This option can only be set at server start.
868 <term>FSYNC (<type>boolean</type>)</term>
871 If this is option is on, the <productname>Postgres</> backend
872 will use the <function>fsync()</> system call in several
873 places to make sure that updates are physically written to
874 disk and will not hang around in the write caches. This
875 increases the chance that a database installation will still
876 be usable after a operating system or hardware crashes by a
877 large amount. (Crashes of the database server itself do
878 <emphasis>not</> affect this consideration.)
882 However, this operation severely slows down
883 <productname>Postgres</>, because at all those points it has
884 to block and wait for the operating system to flush the
885 buffers. Without <function>fsync</>, the operating system is
886 allowed to do its best in buffering, sorting, and delaying
887 writes, so this can be a <emphasis>very</> big perfomance
888 increase. However, if the system crashes, parts of the data of
889 a transaction that has already been committed -- according to
890 the information on disk -- will still hang around in memory.
891 Inconsistent data (i.e., data corruption) is therefore likely
896 This option is the subject of an eternal debate in the
897 <productname>Postgres</> user and developer communities. Some
898 always leave it off, some turn it off only for bulk loads,
899 where there is a clear restart point if something goes wrong,
900 some leave it on just to be on the safe side. Because it is
901 the safe side, on is also the default. If you trust your
902 operating system, your utility company, and your hardware, you
903 might want to disable it.
909 <term>KRB_SERVER_KEYFILE</>
912 Sets the location of the Kerberos server key file. See
913 <xref linkend="kerberos-auth"> for details.
919 <term>MAX_CONNECTIONS (<type>integer</type>)</term>
922 Determines how many concurrent connections the database server
923 will allow. The default is 32. There is also a compiled-in
924 hard upper limit on this value, which is typically 1024
925 (both numbers can be altered when compiling the server). This
926 parameter can only be set at server start.
932 <term>MAX_EXPR_DEPTH (<type>integer</type>)</term>
935 Sets the maximum expression nesting depth that the parser will
936 accept. The default value is high enough for any normal query,
937 but you can raise it if you need to. (But if you raise it too
938 high, you run the risk of backend crashes due to stack
945 <term>PORT (<type>integer</type>)</term>
948 The TCP port the server listens on; 5432 by default. This
949 option can only be set at server start.
955 <term>SHARED_BUFFERS (<type>integer</type>)</term>
958 Sets the number of shared memory buffers the database server
959 will use. The default is 64. Each buffer is typically 8192
960 bytes. This option can only be set at server start.
966 <term>SORT_MEM (<type>integer</type>)</term>
969 Specifies the amount of memory to be used by internal sorts
970 and hashes before resorting to temporary disk files. The value
971 is specified in kilobytes, and defaults to 512 kilobytes. Note
972 that for a complex query, several sorts and/or hashes might be
973 running in parallel, and each one will be allowed to use as
974 much memory as this value specifies before it starts to put
975 data into temporary files.
981 <term>SQL_INHERITANCE (<type>bool</type>)</term>
984 This controls the inheritance semantics, in particular whether
985 subtables are included into the consideration of various
986 commands by default. This was not the case in versions prior
987 to 7.1. If you need the old behaviour you can set this
988 variable to off, but in the long run you are encouraged to
989 change your applications to use the <literal>ONLY</literal>
990 keyword to exclude subtables. See the SQL language reference
991 and the <citetitle>User's Guide</citetitle> for more
992 information about inheritance.
998 <term>SSL (<type>boolean</type>)</term>
1001 Enables <acronym>SSL</> connections. Please read
1002 <xref linkend="ssl"> before using this. The default
1009 <term>TCPIP_SOCKET (<type>boolean</type>)</term>
1012 If this is true, then the server will accept TCP/IP
1013 connections. Otherwise only local Unix domain socket
1014 connections are accepted. It is off by default. This option
1015 can only be set at server start.
1023 <sect2 id="runtime-config-short">
1024 <title>Short options</title>
1026 For convenience there are also single letter option switches
1027 available for many parameters. They are described in the following
1031 <title>Short option key</title>
1033 <colspec colnum="3" align="center">
1036 <entry>Short option</entry>
1037 <entry>Equivalent</entry>
1038 <entry>Remark</entry>
1043 <entry>-B <replaceable>x</replaceable></entry>
1044 <entry>shared_buffers = <replaceable>x</replaceable></entry>
1048 <entry>-d <replaceable>x</replaceable></entry>
1049 <entry>debug_level = <replaceable>x</replaceable></entry>
1054 <entry>fsync = off</entry>
1059 <entry>tcpip_socket = on</entry>
1064 <entry>ssl = on</entry>
1068 <entry>-N <replaceable>x</replaceable></entry>
1069 <entry>max_connections = <replaceable>x</replaceable></entry>
1073 <entry>-p <replaceable>x</replaceable></entry>
1074 <entry>port = <replaceable>x</replaceable></entry>
1079 <entry>-fi, -fh, -fm, -fn, -fs, -ft</entry>
1080 <entry>enable_indexscan=off, enable_hashjoin=off,
1081 enable_mergejoin=off, enable_nestloop=off, enable_seqscan=off,
1082 enable_tidscan=off</entry>
1086 <entry>-S <replaceable>x</replaceable></entry>
1087 <entry>sort_mem = <replaceable>x</replaceable></entry>
1092 <entry>show_query_stats = on</entry>
1096 <entry>-tpa, -tpl, -te</entry>
1097 <entry>show_parser_stats=on, show_planner_stats=on, show_executor_stats=on</entry>
1103 For historical reasons, options marked <quote>*</quote> must be
1104 passed to the individual backend process via the
1105 <option>-o</option> postmaster option, for example,
1107 > <userinput>postmaster -o '-S 1024 -s'</userinput>
1109 or via <envar>PGOPTIONS</envar> from the client side, as explained
1117 <sect1 id="kernel-resources">
1118 <title>Managing Kernel Resources</title>
1121 A large <productname>Postgres</> installation can quickly hit
1122 various operating system resource limits. (On some systems, the
1123 factory defaults are so low that you don't even need a really
1124 <quote>large</> installation.) If you have encountered this kind of
1125 problem then keep reading.
1128 <sect2 id="sysvipc">
1129 <title>Shared Memory and Semaphores</title>
1132 Shared memory and semaphores are collectively referred to as
1133 <quote>System V IPC</> (together with message queues, which are
1134 not relevant for <productname>Postgres</>). Almost all modern
1135 operating systems provide these features, but not all of them have
1136 them turned on or sufficiently sized by default, especially
1137 systems with BSD heritage. (For the QNX port,
1138 <productname>Postgres</> provides its own replacement
1139 implementation of these facilities.)
1143 The complete lack of these facilities is usually manifested by an
1144 <errorname>Illegal system call</> error upon postmaster start. In
1145 that case there's nothing left to do but to reconfigure your
1146 kernel -- <productname>Postgres</> won't work without them.
1150 When <productname>Postgres</> exceeds one of the various hard
1151 limits of the IPC resources then the postmaster will refuse to
1152 start up and should leave a marginally instructive error message
1153 about which problem was encountered and what needs to be done
1154 about it. The relevant kernel parameters have a relatively
1155 consistent nomenclature across systems; <xref
1156 linkend="sysvipc-parameters"> gives an overview. The methods to
1157 set them, however, vary; suggestions for some platforms are given
1158 below. Be aware, however, that you will have to reboot your
1159 machine at best, or possibly recompile the kernel, to change these
1164 <table id="sysvipc-parameters">
1165 <title>System V IPC parameters</>
1171 <entry>Description</>
1172 <entry>Reasonable values</>
1178 <entry><varname>SHMMAX</></>
1179 <entry>Maximum size of shared memory segment (bytes)</>
1180 <entry>512 kB + 8192 * buffers + extra ... infinity</entry>
1184 <entry><varname>SHMMIN</></>
1185 <entry>Minimum size of shared memory segment (bytes)</>
1186 <entry>1 (at most 144)</>
1190 <entry><varname>SHMSEG</></>
1191 <entry>Maximum number of shared memory segments per process</>
1192 <entry>Must be at least 3, but the default is much higher.</>
1196 <entry><varname>SHMMNI</></>
1197 <entry>Maximum number of shared memory segments system-wide</>
1198 <entry>like <varname>SHMSEG</> + room for other applications</>
1202 <entry><varname>SEMMNI</></>
1203 <entry>Maximum number of semaphore identifiers (i.e., sets)</>
1204 <entry>>= ceil(max_connections % 16)</>
1208 <entry><varname>SEMMNS</></>
1209 <entry>Maximum number of semaphores system-wide</>
1210 <entry>number of allowed connections, rounded up to multiple of 16</>
1214 <entry><varname>SEMMSL</></>
1215 <entry>Maximum number of semaphores per set</>
1220 <entry><varname>SEMMAP</></>
1221 <entry>Number of entries in semaphore map</>
1226 <entry><varname>SEMVMX</></>
1227 <entry>Maximum value of semaphore</>
1228 <entry>>= 255 (The default is often 32767, don't change unless asked to.)</>
1237 The most important shared memory parameter is <varname>SHMMAX</>,
1238 the maximum size, in bytes, that a shared memory segment can have.
1239 If you get an error message from <function>shmget</> along the
1240 lines of <errorname>Invalid argument</> then it is possible that
1241 this limit has been exceeded. The size of the required shared
1242 memory segments varies both with the number of requested buffers
1243 (<option>-B</> option) and the number of allowed connections
1244 (<option>-N</> option), although the former is the dominant item.
1245 (You can therefore, as a temporary solution, lower these settings
1246 to get rid of the failures.) As a rough approximation you can
1247 estimate the required segment size as the number of buffers times
1248 the block size (8192 kB by default) plus ample overhead (at least
1249 half a megabyte). Any error message you might get will contain the
1250 size of the failed allocation. (<productname>Postgres</> will
1251 actually use three shared memory segments, but the size of the
1252 other two is negligible for this consideration.)
1256 Less likely to cause problems is the minimum size for shared
1257 memory segments (<varname>SHMMIN</>), which must be at least 144
1258 for <productname>Postgres</> (it's usually just 1), and the
1259 maximum number of segments system-wide (<varname>SHMMNI</>, as
1260 mentioned, 3 are needed) or per-process (<varname>SHMSEG</>,
1261 ditto). Some systems also have a limit on the total amount of
1262 shared memory in the system; see the platform-specific
1267 <productname>Postgres</> uses one semaphore per allowed connection
1268 (<option>-N</> option), in sets of 16. The maximum number of
1269 semaphores in the system is set by <varname>SEMMNS</>, which
1270 consequently must be at least as high as the connection setting.
1271 The parameter <varname>SEMMNI</> determines the limit on the
1272 number of semaphore sets that can exist on the system at one time.
1273 Hence this parameter must be at least
1274 <literal>ceil(max_connections % 16)</>. Lowering the number of
1275 allowed connections is a temporary workaround for failures, which
1276 are usually confusingly worded <quote><errorname>No space left on
1277 device</></>, from the function <function>semget()</>.
1281 In some cases it might also turn out to be necessary to increase
1282 <varname>SEMMAP</> to be at least on the order of
1283 <varname>SEMMNS</>. This parameter defines the size of the
1284 semaphore resource map, in which each contiguous block of available
1285 semaphores needs an entry. When a semaphore set is freed it is
1286 either added to an existing entry that is adjacent to the freed
1287 block or it is registered under a new map entry. If the map is
1288 full, the freed semaphores gets lost (until reboot). Fragmentation
1289 of the semaphore space could therefore over time lead to less
1290 available semaphores than there should be.
1294 The <varname>SEMMSL</> parameter, which determines how many
1295 semaphores can be in a set, must be at least 16 for
1296 <productname>Postgres</>.
1300 Various settings related to <quote>semaphore undo</>, such as
1301 <varname>SEMMNU</> and <varname>SEMUME</>, are not of relevance
1302 with <productname>Postgres</>.
1313 <title>Shared Memory</>
1315 By default, only 4 MB of shared memory is supported. Keep in
1316 mind that shared memory is not pageable; it is locked in RAM.
1317 To increase the number of buffers supported by the
1318 postmaster, increase <varname>SHMMAXPGS</> by 1024 for every
1319 additional 4 MB of shared memory:
1321 /sys/sys/shm.h:69:#define SHMMAXPGS 1024 /* max hardware pages... */
1323 The default setting of 1024 is for a maximum of 4 MB of shared
1329 For those running 4.1 or later, just recompile the kernel and
1330 reboot. For those running earlier releases, use
1331 <application>bpatch</> to find the <varname>sysptsize</> value
1332 for the current kernel. This is computed dynamically at
1335 $ <userinput>bpatch -r sysptsize</>
1336 <computeroutput>0x9 = 9</>
1338 Next, change <varname>SYSPTSIZE</> to a hard-coded value. Use
1339 the bpatch value, plus add 1 for every additional 4 MB of
1340 shared memory you desire.
1342 /sys/i386/i386/i386_param.c:28:#define SYSPTSIZE 0 /* dynamically... */
1344 <varname>sysptsize</> can not be changed by sysctl on the fly.
1348 <title>Semaphores</>
1350 You may need to increase the number of semaphores. By
1351 default, <productname>Postgres</> allocates 32 semaphores,
1352 one for each backend connection. This is just over half the
1353 default system total of 60.
1358 The defaults are in <filename>/sys/sys/sem.h</>:
1360 /* Configuration parameters */
1362 #define SEMMNI 10 /* # of semaphore identifiers */
1365 #define SEMMNS 60 /* # of semaphores in system */
1368 #define SEMUME 10 /* max # of undo entries per process */
1371 #define SEMMNU 30 /* # of undo structures in system */
1374 Set the values you want in your kernel config file, e.g.:
1377 options "SEMMNS=240"
1379 options "SEMMNU=120"
1390 The options <varname>SYSVSHM</> and <varname>SYSVSEM</> need
1391 to be enabled when the kernel is compiled. (They are by
1392 default.) The maximum size of shared memory is determined by
1393 the option <varname>SHMMAXPGS</> (in pages). The following
1394 shows an example on how to set the various parameters:
1397 options SHMMAXPGS=4096
1415 The default settings tend to suffice for normal installations.
1416 On <productname>HPUX</> 10, the factory default for
1417 <varname>SEMMNS</> is 128, which might be too low for larger
1421 IPC parameters can be set in the <application>System
1422 Administration Manager</> (<acronym>SAM</>) under
1423 <menuchoice><guimenu>Kernel
1424 Configuration</><guimenuitem>Configurable Parameters</></>.
1425 Hit <guibutton>Create A New Kernel</> when you're done.
1435 System V IPC is enabled by default and sufficiently sized for
1436 most uses. The relevant parameters are in
1437 <filename>/usr/src/linux/include/asm-<replaceable>xxx</>/shmparam.h</>
1438 and <filename>/usr/src/linux/include/linux/sem.h</>. Be sure
1439 to do <command>make dep</> before rebuilding the kernel.
1446 <term>SCO OpenServer</>
1449 In the default configuration, only 512 kB of shared memory per
1450 segment is allowed, which is about enough for <option>-B 24 -N
1451 12</>. To increase the setting, first change the directory to
1452 <filename>/etc/conf/cf.d</>. To display the current value of
1453 <varname>SHMMAX</>, in bytes, run
1455 ./configure -y SHMMAX
1457 To set a new value for <varname>SHMMAX</>, run:
1459 ./configure SHMMAX=<replaceable>value</>
1461 where <replaceable>value</> is the new value you want to use
1462 (in bytes). After setting <varname>SHMMAX</>, rebuild the kernel
1476 At least in version 2.6, the maximum size of a shared memory
1477 segment is set too low for <productname>Postgres</>. The
1478 relevant settings can be changed in <filename>/etc/system</>,
1481 set shmsys:shminfo_shmmax=0x2000000
1482 set shmsys:shminfo_shmmin=1
1483 set shmsys:shminfo_shmmni=256
1484 set shmsys:shminfo_shmseg=256
1486 set semsys:seminfo_semmap=256
1487 set semsys:seminfo_semmni=512
1488 set semsys:seminfo_semmns=512
1489 set semsys:seminfo_semmsl=32
1491 You need to reboot to make the changes effective.
1496 url="http://www.sunworld.com/swol-09-1997/swol-09-insidesolaris.html">http://www.sunworld.com/swol-09-1997/swol-09-insidesolaris.html</>
1497 for information on shared memory under
1498 <productname>Solaris</>.
1508 On <productname>UnixWare</> 7, the maximum size for shared
1509 memory segments is 512 kB in the default configuration. This
1510 is enough for about <option>-B 24 -N 12</>. To display the
1511 current value of <varname>SHMMAX</>, run
1513 /etc/conf/bin/idtune -g SHMMAX
1515 which displays the current, default, minimum, and maximum
1516 values, in bytes. To set a new value for <varname>SHMMAX</>,
1519 /etc/conf/bin/idtune SHMMAX <replaceable>value</>
1521 where <replaceable>value</> is the new value you want to use
1522 (in bytes). After setting <varname>SHMMAX</>, rebuild the
1525 /etc/conf/bin/idbuild -B
1536 If your platform is not listed here, please consider
1537 contributing some information.
1544 Other fun things to write about one day:
1545 * number of processes per user and system-wide (soft/hard limit)
1546 * open files/inodes per user and system-wide (soft/hard limit)
1547 (Think about this both ways: Increasing it to allow Postgres to
1548 open more files, and decreasing it to prevent Postgres from taking
1549 up all file descriptors.)
1550 * stack and data segment size, plain-old memory limit
1557 <title>Locale Support</title>
1560 <title>Acknowledgement</title>
1562 Written by Oleg Bartunov. See <ulink
1563 url="http://www.sai.msu.su/~megera/postgres/">Oleg's web
1564 page</ulink> for additional information on locale and Russian
1570 While doing a project for a company in Moscow, Russia, I
1571 encountered the problem that <productname>Postgres</> had no
1572 support of national alphabets. After looking for possible
1573 workarounds I decided to develop support of locale myself. I'm not
1574 a C programmer but already had some experience with locale
1575 programming when I work with <productname>Perl</> (debugging) and
1576 <productname>Glimpse</>. After several days of digging through the
1577 <productname>Postgres</> source tree I made very minor corections
1578 to <filename>src/backend/utils/adt/varlena.c</> and
1579 <filename>src/backend/main/main.c</> and got what I needed! I did
1580 support only for <envar>LC_CTYPE</envar> and
1581 <envar>LC_COLLATE</envar>, but later <envar>LC_MONETARY</envar> was
1582 added by others. I got many messages from people about this patch
1583 so I decided to send it to developers and (to my surprise) it was
1584 incorporated into the <productname>Postgres</> distribution.
1588 People often complain that locale doesn't work for them. There are
1589 several common mistakes:
1594 Didn't properly configure <productname>Postgres</> before
1595 compilation. You must run <filename>configure</> with the
1596 <option>--enable-locale</> option to enable locale support.
1602 Didn't setup environment correctly when starting postmaster. You
1603 must define environment variables <envar>LC_CTYPE</envar> and
1604 <envar>LC_COLLATE</envar> before running postmaster because
1605 backend gets information about locale from environment. I use
1606 following shell script:
1610 export LC_CTYPE=koi8-r
1611 export LC_COLLATE=koi8-r
1612 postmaster -B 1024 -S -D/usr/local/pgsql/data/ -o '-Fe'
1619 Broken locale support in the operating system (for example,
1620 locale support in libc under Linux several times has changed and
1621 this caused a lot of problems). Perl has also support of locale
1622 and if locale is broken <command>perl -v</> will complain
1625 <prompt>$</> <userinput>export LC_CTYPE='not_exist'</>
1626 <prompt>$</> <userinput>perl -v</>
1628 perl: warning: Setting locale failed.
1629 perl: warning: Please check that your locale settings:
1631 LC_CTYPE = "not_exist",
1633 are supported and installed on your system.
1634 perl: warning: Falling back to the standard locale ("C").
1642 Wrong location of locale files. Possible locations include:
1643 <filename>/usr/lib/locale</filename> (Linux, Solaris),
1644 <filename>/usr/share/locale</filename> (Linux),
1645 <filename>/usr/lib/nls/loc</filename> (DUX 4.0).
1647 Check <command>man locale</command> to find the correct
1648 location. Under Linux I made a symbolic link between
1649 <filename>/usr/lib/locale</filename> and
1650 <filename>/usr/share/locale</filename> to be sure that the next
1651 libc will not break my locale.
1658 <title>What are the Benefits?</title>
1660 You can use ~* and order by operators for strings contain
1661 characters from national alphabets. Non-english users definitely
1667 <title>What are the Drawbacks?</title>
1669 There is one evident drawback of using locale - its speed! So, use
1670 locale only if you really need it.
1676 <sect1 id="postmaster-shutdown">
1677 <title>Shutting down the server</title>
1680 Depending on your needs, there are several ways to shut down the
1681 database server when your work is done. The differentiation is
1682 done by what signal you send to the server process.
1685 <term>SIGTERM</term>
1688 After receiving SIGTERM, the postmaster disallows new
1689 connections but lets active backend end their work and shuts
1690 down only after all of them terminated (by client request).
1691 This is the <firstterm>Smart Shutdown</firstterm>.
1700 The postmaster disallows new connections, sends all active
1701 backends SIGTERM (which will cause them to abort immediately),
1702 waits for children to exit and shuts down the data base. This
1703 is the <firstterm>Fast Shutdown</firstterm>.
1709 <term>SIGQUIT</term>
1712 This is the <firstterm>Immediate Shutdown</firstterm> which
1713 will cause the postmaster to send a SIGUSR1 to all backends and
1714 exit immediately (without properly shutting down the database
1715 system). When WAL is implemented, this will lead to recovery on
1716 start-up. Right now it's not recommendable to use this option.
1724 If at all possible, do not use SIGKILL to shut down the
1725 postmaster. This can cause data corruption and will prevent the
1726 cleaning up of shared memory resources, which you will have to
1727 do yourself in that case.
1731 The PID of the postmaster process can be found using the
1732 <application>ps</application> program, or from the file
1733 <filename>postmaster.pid</filename> in the data directory. So for
1734 example, to do a fast shutdown:
1736 > <userinput>kill -INT `cat /usr/local/pgsql/data/postmaster.pid`</userinput>
1740 The program <application>pg_ctl</application> is a shell script
1741 wrapper that provides a convenient interface to these functions.
1746 <title>Secure TCP/IP Connections with SSL</title>
1749 <productname>PostgreSQL</> has native support for connections over
1750 <acronym>SSL</> to encrypt
1751 client/server communications for increased security. This requires
1752 <productname>OpenSSL</productname> to be installed on both client
1753 and server systems and support enabled at build-time (see <xref
1754 linkend="installation">).
1758 With SSL support compiled in, the <productname>PostgreSQL</> server
1759 can be started with the argument <option>-l</> (ell) to enable
1760 SSL connections. When starting in SSL mode, the postmaster will look
1761 for the files <filename>server.key</> and <filename>server.crt</> in
1762 the data directory. These files should contain the server private key
1763 and certificate respectively. These files must be set up correctly
1764 before an SSL-enabled server can start. If the private key is protected
1765 with a passphrase, the postmaster will prompt for the passphrase and will
1766 not start until it has been provided.
1770 The postmaster will listen for both standard and SSL connections
1771 on the same TCP/IP port, and will negotiate with any connecting
1772 client wether to use SSL or not. See <xref linkend="client-authentication">
1773 about how to force on the server side the use of SSL for certain
1778 For details on how to create your server private key and certificate,
1779 refer to the <productname>OpenSSL</> documentation. A simple self-signed
1780 certificate can be used to get started testing, but a certificate signed
1781 by a CA (either one of the global CAs or a local one) should be used in
1782 production so the client can verify the servers identity. To create
1783 a quick self-signed certificate, use the <filename>CA.pl</filename>
1784 script included in OpenSSL:
1788 Fill out the information the script asks for. Make sure to enter
1789 the local host name as Common Name. The script will generate a key
1790 that is passphrase protected. To remove the passphrase (required
1791 if you want automatic start-up of the postmaster), run the command
1793 openssl x509 -inform PEM -outform PEM -in newreq.pem -out newkey_no_passphrase.pem
1795 Enter the old passphrase to unlock the existing key. Copy the file
1796 <filename>newreq.pem</> to <filename><replaceable>PGDATA</>/server.crt</>
1797 and <filename>newkey_no_passphrase.pem</> to
1798 <filename><replaceable>PGDATA</>/server.key</>. Remove the PRIVATE KEY part
1799 from the <filename>server.crt</filename> using any text editor.
1804 <title>Secure TCP/IP Connections with SSH tunnels</title>
1807 <title>Acknowledgement</title>
1809 Idea taken from an email by Gene Selkov, Jr.
1810 (<email>selkovjr@mcs.anl.gov</>) written on 1999-09-08 in response
1811 to a question from Eric Marsden.
1816 One can use <productname>ssh</productname> to encrypt the network
1817 connection between clients and a
1818 <productname>Postgres</productname> server. Done properly, this
1819 should lead to an adequately secure network connection.
1823 First make sure that an <productname>ssh</productname> server is
1824 running properly on the same machine as
1825 <productname>Postgres</productname> and that you can log in using
1826 ssh as some user. Then you can establish a secure tunnel with a
1827 command like this from the client machine:
1829 > <userinput>ssh -L 3333:foo.com:5432 joe@foo.com</userinput>
1831 The first number in the <option>-L</option> argument, 3333, is the
1832 port number of your end of the tunnel; it can be chosen freely. The
1833 second number, 5432, is the remote end of the tunnel -- the port
1834 number your backend is using. The name or the address in between
1835 the port numbers is the host with the database server you are going
1836 to connect to. In order to connect to the database server using
1837 this tunnel, you connect to port 3333 on the local machine:
1839 psql -h localhost -p 3333 template1
1841 To the database server it will then look as though you are really
1842 user <literal>joe@foo.com</literal> and it will use whatever
1843 authentication procedure was set up for this user. In order for the
1844 tunnel setup to succeed you must be allowed to connect via ssh as
1845 joe@foo.com, just as if you had attempted to use ssh to set up a
1851 Several other products exist that can provide secure tunnels using
1852 a procedure similar in concept to the one just described.
1860 <!-- Keep this comment at the end of the file
1865 sgml-minimize-attributes:nil
1866 sgml-always-quote-attributes:t
1869 sgml-parent-document:nil
1870 sgml-default-dtd-file:"./reference.ced"
1871 sgml-exposed-tags:nil
1872 sgml-local-catalogs:("/usr/lib/sgml/catalog")
1873 sgml-local-ecat-files:nil