-
-
+
+
commit_delay (integer)
Controls which message levels are written to the server log.
- Valid values are DEBUG5, DEBUG4,
+ Valid values are DEBUG5, DEBUG4,
DEBUG3, DEBUG2, DEBUG1,
INFO, NOTICE, WARNING,
ERROR, LOG, FATAL, and
Controls the amount of detail written in the server log for each
- message that is logged. Valid values are TERSE,
- DEFAULT, and VERBOSE, each adding more
- fields to displayed messages.
+ message that is logged. Valid values are TERSE,
+ DEFAULT, and VERBOSE, each adding more
+ fields to displayed messages.
Here is a list of the various message severity levels used in
- these settings:
+ these settings:
DEBUG[1-5]
This parameter is normally true. When set false, it disables
- validation of the function body string in CREATE FUNCTION.
- Disabling validation is occasionally useful to avoid problems such as
- forward references when restoring function definitions from a dump.
+ validation of the function body string in CREATE FUNCTION.
+ Disabling validation is occasionally useful to avoid problems such as
+ forward references when restoring function definitions from a dump.
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 (ISO,
- Postgres, SQL, or German) and
- the date field order specification (DMY, MDY,
- or YMD). These can be set separately or together.
- The keywords Euro and European are synonyms
- for DMY; the keywords US, NonEuro,
- and NonEuropean are synonyms for MDY.
- See for more information. The
+ For historical reasons, this variable contains two independent
+ components: the output format specification (ISO,
+ Postgres, SQL, or German) and
+ the date field order specification (DMY, MDY,
+ or YMD). These can be set separately or together.
+ The keywords Euro and European are synonyms
+ for DMY; the keywords US, NonEuro,
+ and NonEuropean are synonyms for MDY.
+ See for more information. The
default is ISO, MDY.
When true, tables that are referenced by a query will be
- automatically added to the FROM clause if not already
- present. The default is true for compatibility with
- previous releases of
PostgreSQL. However, this- behavior is not SQL-standard, and many people dislike it because it
- can mask mistakes. Set to false for the SQL-standard
- behavior of rejecting references to tables that are not listed in
- FROM.
+ automatically added to the FROM clause if not already
+ present. The default is true for compatibility with
+
previous releases of
PostgreSQL. However, this+ behavior is not SQL-standard, and many people dislike it because it
+ can mask mistakes. Set to false for the SQL-standard
+ behavior of rejecting references to tables that are not listed in
+ FROM.
If nonzero, a delay of this many seconds occurs just after a new
- server process is forked, before it conducts the authentication
- process. This is intended to give an opportunity to attach to the
- server process with a debugger to trace down misbehavior in
- authentication.
+ server process is forked, before it conducts the authentication
+ process. This is intended to give an opportunity to attach to the
+ server process with a debugger to trace down misbehavior in
+ authentication.
option singular.)
- You might also want to use the sysctl setting to
- lock shared memory into RAM and prevent it from being paged out
- to swap, e.g. kern.ipc.shm_use_phys.
+ You might also want to configure your kernel to lock shared
+ memory into RAM and prevent it from being paged out to swap.
+ Use the sysctl setting
+ kern.ipc.shm_use_phys.
/usr/src/linux/include/asm-xxx/shmpara
m.h and /usr/src/linux/include/linux/sem.h.
-
- Linux kernel version 2.4.* has poor default memory overcommit
- behavior, which can result in the postmaster being killed by the
- kernel due to memory demands by another process if the system
- runs out of memory.
-
-
- The symptom of this occurring is a kernel message looking like
- this (consult your system documentation and configuration on
- where to look for such a message):
- Out of Memory: Killed process 12345 (postmaster).
-
-
-
- To avoid this situation, run
PostgreSQL - on a machine where you
- can be sure that other processes will not run the machine out
- of memory. If your kernel supports strict and/or paranoid modes
- of overcommit handling, you can also relieve this problem by
- altering the system's default behaviour. This can be determined
- by examining the function vm_enough_memory
- in the file mm/mmap.c in the kernel source.
- If this file reveals that strict and/or paranoid modes are
- supported by your kernel, turn one of these modes on by using
-sysctl -w vm.overcommit_memory=2
-
- for strict mode or
-sysctl -w vm.overcommit_memory=3
-
- for paranoid mode, or placing an equivalent entry in
- /etc/sysctl.conf.
-
-
-
- Warning: using these settings in a kernel which does not support
- these modes will almost certainly increase the danger of the
- kernel killing the postmaster, rather than reducing it.
- If in any doubt, consult a kernel expert or your kernel vendor.
-
-
-
- These modes are expected to be supported in all 2.6 and later
- kernels. Some vendor 2.4 kernels may also support these modes.
- However, it is known that some vendor documents suggest that
- they support them while examination of the kernel source reveals
- that they do not.
-
-
- Note, you will need enough swap space to cover all your memory needs.
-
+
+
Linux Memory Overcommit
+
+ Linux kernels of version 2.4.* have a poor default memory
+ overcommit behavior, which can result in the PostgreSQL server
+ (postmaster process) being killed by the
+ kernel if the memory demands of another process cause the system
+ to run out of memory.
+
+
+ If this happens, you will see a kernel message looking like this
+ (consult your system documentation and configuration on where to
+ look for such a message):
+Out of Memory: Killed process 12345 (postmaster).
+
+ And, of course, you will find that your database server has
+ disappeared.
+
+
+ To avoid this situation, run
PostgreSQL+ on a machine where you can be sure that other processes will not
+ run the machine out of memory. If your kernel supports the strict
+ and/or paranoid modes of overcommit handling, you can also relieve
+ this problem by altering the system's default behaviour. This can
+ be determined by examining the function
+ vm_enough_memory in the file mm/mmap.c
+ in the kernel source. If this file reveals that the strict and/or
+ paranoid modes are supported by your kernel, turn one of these
+ modes on by using
+sysctl -w vm.overcommit_memory=2
+
+ for strict mode, or
+sysctl -w vm.overcommit_memory=3
+
+ for paranoid mode, or placing an equivalent entry in
+ /etc/sysctl.conf.
+
+
+
+ Using these settings in a kernel which does not support these
+ modes will almost certainly increase the danger of the kernel
+ killing the database server, rather than reducing it. If in any
+ doubt, consult a kernel expert or your kernel vendor.
+
+
+
+ These modes are expected to be supported in all 2.6 and later
+ kernels. Some vendor 2.4 kernels may also support these modes. It
+ is, however, known that some vendor documents suggest that they
+ support them while examination of the kernel source reveals that
+ they do not.
+
+
+ Note, you will need enough swap space to cover all your memory needs.
+
+
projects / postgresql.git / commitdiff