On Mon, 2008-02-25 at 17:56 +0600, Markus Bertheau wrote:
> 2008/2/22, Simon Riggs <[EMAIL PROTECTED]>:
> > If you have some suggested changes, I'd be happy to hear them.
> >
> > Probably additions are better than just changes though.
>
> What about this:
>
> *** a/doc/src/sgml/backup.sgml
> --- b/doc/src/sgml/backup.sgml
> ***************
...
> The FIXME of course needs replacement by someone in the know.
Doc patch edited to include all of Markus' points, tidy up some related
text and fix typos.
Good to apply to HEAD.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk
Index: doc/src/sgml/backup.sgml
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/doc/src/sgml/backup.sgml,v
retrieving revision 2.115
diff -c -r2.115 backup.sgml
*** doc/src/sgml/backup.sgml 7 Mar 2008 01:46:41 -0000 2.115
--- doc/src/sgml/backup.sgml 28 Mar 2008 13:08:38 -0000
***************
*** 577,587 ****
<para>
It is important that the archive command return zero exit status if and
only if it succeeded. Upon getting a zero result,
! <productname>PostgreSQL</> will assume that the WAL segment file has been
! successfully archived, and will remove or recycle it.
! However, a nonzero status tells
! <productname>PostgreSQL</> that the file was not archived; it will try
! again periodically until it succeeds.
</para>
<para>
--- 577,586 ----
<para>
It is important that the archive command return zero exit status if and
only if it succeeded. Upon getting a zero result,
! <productname>PostgreSQL</> will assume that the file has been
! successfully archived, and will remove or recycle it. However, a nonzero
! status tells <productname>PostgreSQL</> that the file was not archived;
! it will try again periodically until it succeeds.
</para>
<para>
***************
*** 1001,1011 ****
<para>
It is important that the command return nonzero exit status on failure.
! The command <emphasis>will</> be asked for log files that are not present
in the archive; it must return nonzero when so asked. This is not an
! error condition. Be aware also that the base name of the <literal>%p</>
! path will be different from <literal>%f</>; do not expect them to be
! interchangeable.
</para>
<para>
--- 1000,1012 ----
<para>
It is important that the command return nonzero exit status on failure.
! The command <emphasis>will</> be asked for files that are not present
in the archive; it must return nonzero when so asked. This is not an
! error condition. Not all of the requested files will be WAL segment
! files. You should also expect requests for files with a suffix of
! <literal>.backup</> or <literal>.history</>. Also be aware also that
! the base name of the <literal>%p</> path will be different from
! <literal>%f</>; do not expect them to be interchangeable.
</para>
<para>
***************
*** 1576,1594 ****
<para>
The magic that makes the two loosely coupled servers work together is
! simply a <varname>restore_command</> used on the standby that waits
! for the next WAL file to become available from the primary. The
! <varname>restore_command</> is specified in the
<filename>recovery.conf</> file on the standby server. Normal recovery
processing would request a file from the WAL archive, reporting failure
if the file was unavailable. For standby processing it is normal for
! the next file to be unavailable, so we must be patient and wait for
! it to appear. A waiting <varname>restore_command</> can be written as
! a custom script that loops after polling for the existence of the next
! WAL file. There must also be some way to trigger failover, which should
! interrupt the <varname>restore_command</>, break the loop and return
! a file-not-found error to the standby server. This ends recovery and
! the standby will then come up as a normal server.
</para>
<para>
--- 1577,1598 ----
<para>
The magic that makes the two loosely coupled servers work together is
! simply a <varname>restore_command</> used on the standby that,
! when asked for the next WAL file, waits for it to become available from
! the primary. The <varname>restore_command</> is specified in the
<filename>recovery.conf</> file on the standby server. Normal recovery
processing would request a file from the WAL archive, reporting failure
if the file was unavailable. For standby processing it is normal for
! the next WAL file to be unavailable, so we must be patient and wait for
! it to appear. For files ending in <literal>.backup</> or
! <literal>.history</> there is no need to wait, though a non-zero return
! code should also be returned in this case. A waiting
! <varname>restore_command</> can be written as a custom script that loops
! after polling for the existence of the next WAL file. There must also be
! some way to trigger failover, which should interrupt the
! <varname>restore_command</>, break the loop and return a file-not-found
! error to the standby server. This ends recovery and the standby will then
! come up as a normal server.
</para>
<para>
***************
*** 1608,1616 ****
<para>
A working example of a waiting <varname>restore_command</> is provided
! as a <filename>contrib</> module named <application>pg_standby</>. This
! example can be extended as needed to support specific configurations or
! environments.
</para>
<para>
--- 1612,1621 ----
<para>
A working example of a waiting <varname>restore_command</> is provided
! as a <filename>contrib</> module named <application>pg_standby</>. It
! should be used as a reference on how to correctly implement the logic
! described above. It can also be extended as needed to support specific
! configurations or environments.
</para>
<para>
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
