Move recovery_init_sync_method GUC to WAL_RECOVERY group

The recovery_init_sync_method GUC was separated from all other recovery
related GUCS in our docs. This made it pretty hard to find in the docs
if you don't know exactly what you're looking for. This moves it to the
generic "Recovery" section on the WAL page. While it's not really
related to WAL it still seems a much more natural place than the "Error
handling" page. Especially because of the description of this subheading:

> This section describes the settings that apply to recovery in general,
> affecting crash recovery, streaming replication and archive-based
> replication.

To make this doc change it also updates the group and place in
postgresql.conf accordingly. The latter of which also required changing
the section header in postgresql.conf.sample to match the header in the
docs.

The only recovery related GUC that exists that's not on the WAL page is
recovery_min_apply_delay, which is under the Replication->Standby
section. Since that GUC is only valid on standbys that seems like a
sensible choice.

Author: JelteF

doc/src/sgml/config.sgml

@@ -4246,6 +4246,45 @@ include_dir 'conf.d'
       </listitem>
      </varlistentry>
 
+     <varlistentry id="guc-recovery-init-sync-method" xreflabel="recovery_init_sync_method">
+      <term><varname>recovery_init_sync_method</varname> (<type>enum</type>)
+       <indexterm>
+        <primary><varname>recovery_init_sync_method</varname> configuration parameter</primary>
+       </indexterm>
+      </term>
+      <listitem>
+       <para>
+        When set to <literal>fsync</literal>, which is the default,
+        <productname>PostgreSQL</productname> will recursively open and
+        synchronize all files in the data directory before crash recovery
+        begins.  The search for files will follow symbolic links for the WAL
+        directory and each configured tablespace (but not any other symbolic
+        links).  This is intended to make sure that all WAL and data files are
+        durably stored on disk before replaying changes.  This applies whenever
+        starting a database cluster that did not shut down cleanly, including
+        copies created with <application>pg_basebackup</application>.
+       </para>
+       <para>
+        On Linux, <literal>syncfs</literal> may be used instead, to ask the
+        operating system to synchronize the file systems that contain the
+        data directory, the WAL files and each tablespace (but not any other
+        file systems that may be reachable through symbolic links).  This may
+        be a lot faster than the <literal>fsync</literal> setting, because it
+        doesn't need to open each file one by one.  On the other hand, it may
+        be slower if a file system is shared by other applications that
+        modify a lot of files, since those files will also be written to disk.
+        Furthermore, on versions of Linux before 5.8, I/O errors encountered
+        while writing data to disk may not be reported to
+        <productname>PostgreSQL</productname>, and relevant error messages may
+        appear only in kernel logs.
+       </para>
+       <para>
+        This parameter can only be set in the
+        <filename>postgresql.conf</filename> file or on the server command line.
+       </para>
+      </listitem>
+     </varlistentry>
+
     </variablelist>
    </sect2>
 
@@ -12269,45 +12308,6 @@ dynamic_library_path = '/usr/local/lib/postgresql:$libdir'
       </listitem>
      </varlistentry>
 
-     <varlistentry id="guc-recovery-init-sync-method" xreflabel="recovery_init_sync_method">
-      <term><varname>recovery_init_sync_method</varname> (<type>enum</type>)
-       <indexterm>
-        <primary><varname>recovery_init_sync_method</varname> configuration parameter</primary>
-       </indexterm>
-      </term>
-      <listitem>
-       <para>
-        When set to <literal>fsync</literal>, which is the default,
-        <productname>PostgreSQL</productname> will recursively open and
-        synchronize all files in the data directory before crash recovery
-        begins.  The search for files will follow symbolic links for the WAL
-        directory and each configured tablespace (but not any other symbolic
-        links).  This is intended to make sure that all WAL and data files are
-        durably stored on disk before replaying changes.  This applies whenever
-        starting a database cluster that did not shut down cleanly, including
-        copies created with <application>pg_basebackup</application>.
-       </para>
-       <para>
-        On Linux, <literal>syncfs</literal> may be used instead, to ask the
-        operating system to synchronize the file systems that contain the
-        data directory, the WAL files and each tablespace (but not any other
-        file systems that may be reachable through symbolic links).  This may
-        be a lot faster than the <literal>fsync</literal> setting, because it
-        doesn't need to open each file one by one.  On the other hand, it may
-        be slower if a file system is shared by other applications that
-        modify a lot of files, since those files will also be written to disk.
-        Furthermore, on versions of Linux before 5.8, I/O errors encountered
-        while writing data to disk may not be reported to
-        <productname>PostgreSQL</productname>, and relevant error messages may
-        appear only in kernel logs.
-       </para>
-       <para>
-        This parameter can only be set in the
-        <filename>postgresql.conf</filename> file or on the server command line.
-       </para>
-      </listitem>
-     </varlistentry>
-
     </variablelist>
 
    </sect1>

src/backend/utils/misc/guc_parameters.dat

@@ -2450,7 +2450,7 @@
   boot_val => '""',
 },
 
-{ name => 'recovery_init_sync_method', type => 'enum', context => 'PGC_SIGHUP', group => 'ERROR_HANDLING_OPTIONS',
+{ name => 'recovery_init_sync_method', type => 'enum', context => 'PGC_SIGHUP', group => 'WAL_RECOVERY',
   short_desc => 'Sets the method for synchronizing the data directory before crash recovery.',
   variable => 'recovery_init_sync_method',
   boot_val => 'DATA_DIR_SYNC_METHOD_FSYNC',

src/backend/utils/misc/postgresql.conf.sample

@@ -283,11 +283,12 @@
 #max_wal_size = 1GB
 #min_wal_size = 80MB
 
-# - Prefetching during recovery -
+# - Recovery -
 
-#recovery_prefetch = try        # prefetch pages referenced in the WAL?
-#wal_decode_buffer_size = 512kB # lookahead window used for prefetching
-                                # (change requires restart)
+#recovery_prefetch = try                # prefetch pages referenced in the WAL?
+#wal_decode_buffer_size = 512kB         # lookahead window used for prefetching
+                                        # (change requires restart)
+#recovery_init_sync_method = fsync      # fsync, syncfs (Linux 5.8+)
 
 # - Archiving -
 
@@ -912,7 +913,6 @@
 #data_sync_retry = off                  # retry or panic on failure to fsync
                                         # data?
                                         # (change requires restart)
-#recovery_init_sync_method = fsync      # fsync, syncfs (Linux 5.8+)
 
 
 #------------------------------------------------------------------------------