Re: WIP: WAL prefetch (another approach)

The docs seem to be wrong about the default.

+ are not yet in the buffer pool, during recovery. Valid values are
+ <literal>off</literal> (the default), <literal>on</literal> and
+ <literal>try</literal>. The setting <literal>try</literal> enables

+ concurrency and distance, respectively. By default, it is set to
+ <literal>try</literal>, which enabled the feature on systems where
+ <function>posix_fadvise</function> is available.

Should say "which enables".

+ {
+ {"recovery_prefetch", PGC_SIGHUP, WAL_RECOVERY,
+ gettext_noop("Prefetch referenced blocks during recovery"),
+ gettext_noop("Look ahead in the WAL to find references to uncached data.")
+ },
+ &recovery_prefetch,
+ RECOVERY_PREFETCH_TRY, recovery_prefetch_options,
+ check_recovery_prefetch, assign_recovery_prefetch, NULL
+ },

Curiously, I reported a similar issue last year.

On Thu, Apr 08, 2021 at 10:37:04PM -0500, Justin Pryzby wrote:
> --- a/doc/src/sgml/wal.sgml
> +++ b/doc/src/sgml/wal.sgml
> @@ -816,9 +816,7 @@
> prefetching mechanism is most likely to be effective on systems
> with <varname>full_page_writes</varname> set to
> <varname>off</varname> (where that is safe), and where the working
> - set is larger than RAM. By default, prefetching in recovery is enabled
> - on operating systems that have <function>posix_fadvise</function>
> - support.
> + set is larger than RAM. By default, prefetching in recovery is disabled.
> </para>
> </sect1>