From: | "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi(dot)shinoda(at)hpe(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, 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-12 09:01:51 |
Message-ID: | PH7PR84MB1885401C5FAECB66521E7F91EEED9@PH7PR84MB1885.NAMPRD84.PROD.OUTLOOK.COM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Thank you for developing the great feature. I tested this feature and checked the documentation. Currently, the documentation for the pg_stat_prefetch_recovery view is included in the description for the pg_stat_subscription view.
https://www.postgresql.org/docs/devel/monitoring-stats.html#MONITORING-PG-STAT-SUBSCRIPTION
It is also not displayed in the list of "28.2. The Statistics Collector".
https://www.postgresql.org/docs/devel/monitoring.html
The attached patch modifies the pg_stat_prefetch_recovery view to appear as a separate view.
Regards,
Noriyoshi Shinoda
-----Original Message-----
From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Sent: Friday, April 8, 2022 10:47 AM
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)
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.
Attachment | Content-Type | Size |
---|---|---|
pg_stat_recovery_prefetch_doc_v1.diff | application/octet-stream | 2.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2022-04-12 09:05:44 | Re: row filtering for logical replication |
Previous Message | Dong Wook Lee | 2022-04-12 08:48:40 | GSoC: Improve PostgreSQL Regression Test Coverage |