docs: Note the recovery_min_apply_delay bloats pg_wal.

Those WAL files that we're waiting to apply have to be stored
somewhere.

Thom Brown

Discussion: http://postgr.es/m/CAA-aLv4SkJRK6GGcd0Axt8kt6_eWMEbtG7f8NJpFh+rNshtdNA@mail.gmail.com

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 81cacdcbe40e3e6a07fa5f26f848f1e084d71696..cfbb20a39e131a9e37043492fe4b0767b22da2c5 100644 (file)
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4872,6 +4872,12 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
         state, until the standby is promoted or triggered. After that the standby
         will end recovery without further waiting.
        </para>
+       <para>
+        WAL records must be kept on the standby until they are ready to be
+        applied. Therefore, longer delays will result in a greater accumulation
+        of WAL files, increasing disk space requirements for the standby's
+        <filename>pg_wal</filename> directory.
+       </para>
        <para>
         This parameter is intended for use with streaming replication deployments;
         however, if the parameter is specified it will be honored in all cases