From: Justin Pryzby <pryzby@telsasoft.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Andres Freund <andres@anarazel.de>
Cc: Jakub Wartak <Jakub.Wartak@tomtom.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: David Steele <david@pgmasters.net>
Cc: pgsql-hackers@postgresql.org
Subject: Re: WIP: WAL prefetch (another approach)
Date: Thu, 7 Apr 2022 07:55:55 -0500
Message-ID: <20220407125555.GC24419@telsasoft.com> (raw)
In-Reply-To: <20210409033703.GP6592@telsasoft.com>
References: <eed83eaa-91e1-91fe-32d0-ece36c0fa810@enterprisedb.com>
<20210214231815.GO27507@tamriel.snowman.net>
<17b3f450-048c-f3a6-7086-259523f33cbc@enterprisedb.com>
<20210317214331.GF20766@tamriel.snowman.net>
<28c3352e-5388-6410-aae7-05907079e6c9@enterprisedb.com>
<CA+hUKGLHTjbBPFX6E1ZCGVyQD30-vWtH=N6EcHEzW13q+jh7FQ@mail.gmail.com>
<8dd2dcc2-0b6b-a4ab-c1b3-032c0a5ab1c3@enterprisedb.com>
<CA+hUKGKmkKfH1h9XG5ctYCgqeOHGdN5bHMoQMZLR=+kLY0PQzA@mail.gmail.com>
<CA+hUKGLsF8sEE+n3qoaV6+XjmYEwYoFVDbLPbYTGz7oGkL=iZA@mail.gmail.com>
<20210409033703.GP6592@telsasoft.com>
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>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com, thomas.munro@gmail.com, tomas.vondra@enterprisedb.com, sfrost@snowman.net, andres@anarazel.de, Jakub.Wartak@tomtom.com, alvherre@2ndquadrant.com, tomas.vondra@2ndquadrant.com, 9erthalion6@gmail.com, david@pgmasters.net
Subject: Re: WIP: WAL prefetch (another approach)
In-Reply-To: <20220407125555.GC24419@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox