From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Jakub Wartak <Jakub(dot)Wartak(at)tomtom(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: WAL prefetch (another approach) |
Date: | 2022-04-08 01:46:49 |
Message-ID: | CA+hUKGL4V4UvdJ+RFxCdp0Lq=63jit-7=SVZeyNQaWJtCEuPRw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 8, 2022 at 12:55 AM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> 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
Fixed.
> + 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".
Fixed.
> Curiously, I reported a similar issue last year.
Sorry. I guess both times we only agreed on what the default should
be in the final review round before commit, and I let the docs get out
of sync (well, the default is mentioned in two places and I apparently
ended my search too soon, changing only one). I also found another
recently obsoleted sentence: the one about showing nulls sometimes was
no longer true. Removed.
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2022-04-08 02:10:14 | Re: shared-memory based stats collector - v70 |
Previous Message | Kyotaro Horiguchi | 2022-04-08 01:34:55 | Re: API stability |