github/repmgr
1
0
Fork 0
mirror of https://github.com/EnterpriseDB/repmgr.git synced 2026-03-27 17:06:29 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

doc: fix typos etc. in "standby follow" reference

Browse Source
This commit is contained in:
Ian Barwick
2019-02-12 17:24:56 +09:00
parent f2362a06fa
commit 905e108f8f
1 changed files with 7 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
doc/repmgr-standby-follow.sgml
View File

@@ -58,9 +58,9 @@
WAL. WAL.
</para> </para>
<para> <para>
Conversely, if the standby is attached follows another standby Conversely, if the standby is attached to an upstream standby
with <option>recovery_min_apply_delay</option> set, that standby's replay which has <option>recovery_min_apply_delay</option> set, the upstream
state may actually be behind that of its new downstream node. standby's replay state may actually be behind that of its new downstream node.
</para> </para>
</note> </note>
@@ -173,7 +173,7 @@ DETAIL: follow target server's timeline 2 forked off current database system tim
In this case, it may be possible to have this node follow the new upstream In this case, it may be possible to have this node follow the new upstream
using <command><link linkend="repmgr-node-rejoin">repmgr node rejoin</link></command> using <command><link linkend="repmgr-node-rejoin">repmgr node rejoin</link></command>
with the <option>--force-rewind</option> to execute <command>pg_rewind</command>. with the <option>--force-rewind</option> to execute <command>pg_rewind</command>.
This does mean that transacations which exist on this node, but not the new upstream, This does mean that transactions which exist on this node, but not the new upstream,
will be lost. will be lost.
</para> </para>