Skip to content

Commit bfdabf3

Browse files
committed
[Issue #66] documentation update
1 parent 2cb4326 commit bfdabf3

File tree

1 file changed

+13
-4
lines changed

1 file changed

+13
-4
lines changed

doc/pgprobackup.xml

+13-4
Original file line numberDiff line numberDiff line change
@@ -1746,10 +1746,19 @@ pg_probackup restore -B <replaceable>backup_dir</replaceable> --instance <replac
17461746
all data files in the data directory, validate header and checksum in
17471747
every page and replace only invalid pages and those with LSN greater
17481748
than shiftpoint.
1749-
This mode offer a greatest speed up, but rely on <replaceable>pg_control</replaceable>
1750-
been synched with state of data directory,
1751-
so it is not recommended to use in any situation, where this condition
1752-
is not met, for example, after <replaceable>pg_resetxlog</replaceable> execution,
1749+
This mode offer a far greater speed up compared to CHECKSUM, but rely
1750+
on two conditions to be met. First,
1751+
<ulink url="https://postgrespro.com/docs/postgresql/current/runtime-config-preset.html#GUC-DATA-CHECKSUMS">
1752+
data checksums</ulink> parameter must be enabled in data directory (to avoid corruption
1753+
due to hint bits). This condition will be checked at the start of
1754+
incremental restore and the operation will be aborted if checksums are disabled.
1755+
Second, the <replaceable>pg_control</replaceable> file must be
1756+
synched with state of data directory. This condition cannot checked
1757+
at the start of restore, so it is a user responsibility to ensure
1758+
that pg_control contain valid information. Because of that is not
1759+
recommended to use LSN mode in any situation, where pg_control has
1760+
been tampered with:
1761+
after <replaceable>pg_resetxlog</replaceable> execution,
17531762
after restore from backup without recovery been run, etc.
17541763
</para>
17551764
</listitem>

0 commit comments

Comments
 (0)