postgres.git / summary / log / commit / refs

commit    7ff7c0d7b71c6ec638549c3accd54ccdddf3232e
Author:   Michael Paquier <michael@paquier.xyz>
Date:     Fri Apr 05 01:38:41 2019 +0000
First released in: 12.0, 9.5.17, 9.6.13, 10.8, 11.3

    Fix some documentation in pg_rewind
    
    A confusion which comes a lot from users is that it is necessary to
    issue a checkpoint on a freshly-promoted standby so as its control file
    has up-to-date timeline information which is used by pg_rewind to
    validate the operation.  Let's document that properly.  This is
    back-patched down to 9.5 where pg_rewind has been introduced.
    
    Author: Michael Paquier
    Reviewed-by: Magnus Hagander
    Discussion: https://postgr.es/m/CABUevEz5bpvbwVsYCaSMV80CBZ5-82nkMzbb+Bu=h1m=rLdn=g@mail.gmail.com
    Backpatch-through: 9.5


 doc/src/sgml/ref/pg_rewind.sgml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/src/sgml/ref/pg_rewind.sgml b/doc/src/sgml/ref/pg_rewind.sgml
index 32e6d0445f6..d3899a4706d 100644
--- a/doc/src/sgml/ref/pg_rewind.sgml
+++ b/doc/src/sgml/ref/pg_rewind.sgml
@@ -221,6 +221,15 @@ PostgreSQL documentation
  <refsect1>
   <title>Notes</title>
 
+  <para>
+   When executing <application>pg_rewind</application> using an online
+   cluster as source which has been recently promoted, it is necessary
+   to execute a <command>CHECKPOINT</command> after promotion so as its
+   control file reflects up-to-date timeline information, which is used by
+   <application>pg_rewind</application> to check if the target cluster
+   can be rewound using the designated source cluster.
+  </para>
+
   <refsect2>
    <title>How it works</title>
 


[parent: 331f152884f2]