This allows all complexity to be managed within the script, which

can be written in a popular scripting language such as

<application>bash</> or <application>perl</>.

Any messages written to <literal>stderr</> from the script will appear

in the database server log, allowing complex configurations to be

diagnosed easily if they fail.

</para>

<para>

</listitem>

</itemizedlist>

</para>

<tip>

<para>

When using an <varname>archive_command</varname> script, it's desirable

to enable <xref linkend="guc-logging-collector">.

Any messages written to <systemitem>stderr</> from the script will then

appear in the database server log, allowing complex configurations to

be diagnosed easily if they fail.

</para>

</tip>

</sect3>

</sect2>

value</> (<acronym>CSV</>) format, which is convenient for

loading logs into programs.

See <xref linkend="runtime-config-logging-csvlog"> for details.

<varname>logging_collector</varname> must be enabled to generate

<xref linkend="guc-logging-collector"> must be enabled to generate

CSV-format log output.

</para>

</indexterm>

<listitem>

<para>

This parameter captures plain and CSV-format log messages

sent to <application>stderr</> and redirects them into log files.

This parameter enables the <firstterm>logging collector</>, which

is a background process that captures log messages

sent to <systemitem>stderr</> and redirects them into log files.

This approach is often more useful than

logging to <application>syslog</>, since some types of messages

might not appear in <application>syslog</> output (a common example

is dynamic-linker failure messages).

might not appear in <application>syslog</> output. (One common

example is dynamic-linker failure messages; another is error messages

produced by scripts such as <varname>archive_command</>.)

This parameter can only be set at server start.

</para>

<note>

<para>

It is possible to log to <systemitem>stderr</> without using the

logging collector; the log messages will just go to wherever the

server's <systemitem>stderr</> is directed. However, that method is

only suitable for low log volumes, since it provides no convenient

way to rotate log files. Also, on some platforms not using the

logging collector can result in lost or garbled log output, because

multiple processes writing concurrently to the same log file can

overwrite each other's output.

</para>

</note>

<note>

<para>

The logging collector is designed to never lose messages. This means

that in case of extremely high load, server processes could be

blockeddue to trying to send additional log messages when the

blockedwhile trying to send additional log messages when the

collector has fallen behind. In contrast, <application>syslog</>

prefers to drop messages if it cannot write them, which means it's

less reliableinthose cases but it will not block the rest of the

system.

prefers to drop messages if it cannot write them, which means it

may fail to log some messagesinsuch cases but it will not block

the rest of thesystem.

</para>

</note>