|
1 | | -<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.42 2010/02/12 14:53:22 heikki Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.43 2010/02/13 03:38:26 momjian Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="high-availability"> |
4 | 4 | <title>High Availability, Load Balancing, and Replication</title> |
@@ -873,9 +873,9 @@ if (!triggered) |
873 | 873 | <term><varname>restore_end_command</varname> (<type>string</type>)</term> |
874 | 874 | <listitem> |
875 | 875 | <para> |
876 | | - In standby-mode, <varname>restore_command</> (and <varname>restore_end_command</>) is set to a |
877 | | - simple command or script like in PITR. pg_standby or similar tools |
878 | | - that wait for the next WAL file to arrive, cannot be used with |
| 876 | + In standby-mode, <varname>restore_command</> (and <varname>restore_end_command</>) is set to a |
| 877 | + simple command or script like in PITR. pg_standby or similar tools |
| 878 | + that wait for the next WAL file to arrive, cannot be used with |
879 | 879 | streaming replication, as the server handles retries and waiting |
880 | 880 | itself. Set <varname>restore_command</> as you would if you were |
881 | 881 | recovering using a Continuous archiving backup (see <xref linkend="backup-pitr-recovery">). |
|