Improve documentation around logging_collector and use of stderr.

In backup.sgml, point out that you need to be using the logging collector
if you want to log messages from a failing archive_command script.  (This
is an oversimplification, in that it will work without the collector as
long as you're not sending postmaster stderr to /dev/null; but it seems
like a good idea to encourage use of the collector to avoid problems
with multiple processes concurrently scribbling on one file.)

In config.sgml, do some wordsmithing of logging_collector discussion.

Per bug #6518 from Janning Vygen

diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index cbaff17bb3e0f352154405d0a88d113ddb833810..4d6ffc4fef24f1d14fd9ecc298ef970d5915d38c 100644 (file)
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1387,9 +1387,6 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
       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>
@@ -1418,6 +1415,16 @@ archive_command = 'local_backup_script.sh "%p" "%f"'
        </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>