diff options
| author | Michael Paquier | 2019-04-05 01:38:41 +0000 |
|---|---|---|
| committer | Michael Paquier | 2019-04-05 01:38:41 +0000 |
| commit | 7ff7c0d7b71c6ec638549c3accd54ccdddf3232e (patch) | |
| tree | f5d7cf1127dae8f924bd02afa517f5a009408716 | |
| parent | 331f152884f2bdf92c61432ef2d10239e67c663c (diff) | |
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
| -rw-r--r-- | doc/src/sgml/ref/pg_rewind.sgml | 9 |
1 files changed, 9 insertions, 0 deletions
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> |