[PGDOCS] Inconsistent linkends to "monitoring" views.
I noticed one or two "monitoring" links and linkends that are slightly
inconsistent from all the others.
~~~
From "Dynamic Statistics Views"
pg_stat_activity, linkend="monitoring-pg-stat-activity-view" ==> ok
pg_stat_replication, linkend="monitoring-pg-stat-replication-view" ==> ok
pg_stat_wal_receiver, linkend="monitoring-pg-stat-wal-receiver-view"> ==> ok
pg_stat_recovery_prefetch,
linkend="monitoring-pg-stat-recovery-prefetch" ==> MODIFY
linkend="monitoring-pg-stat-recovery-prefetch-view"
pg_stat_subscription, linkend="monitoring-pg-stat-subscription" ==>
MODIFY linkend="monitoring-pg-stat-subscription-view"
pg_stat_ssl, linkend="monitoring-pg-stat-ssl-view" ==> ok
~~~
From "Collected Statistics Views"
pg_stat_archiver, linkend="monitoring-pg-stat-archiver-view" ==> ok
pg_stat_bgwriter, linkend="monitoring-pg-stat-bgwriter-view" ==> ok
pg_stat_database, linkend="monitoring-pg-stat-database-view" ==> ok
pg_stat_database_conflicts,
linkend="monitoring-pg-stat-database-conflicts-view" ==> ok
pg_stat_io, linkend="monitoring-pg-stat-io-view"> ==> ok
pg_stat_replication_slots,
linkend="monitoring-pg-stat-replication-slots-view" ==> ok
pg_stat_slru, linkend="monitoring-pg-stat-slru-view" ==> ok
pg_stat_subscription_stats,
linkend="monitoring-pg-stat-subscription-stats" ==> MODIFY
linkend="monitoring-pg-stat-subscription-stats-view"
pg_stat_wal, linkend="monitoring-pg-stat-wal-view" ==> ok
pg_stat_all_tables, linkend="monitoring-pg-stat-all-tables-view" ==> ok
pg_stat_all_indexes, linkend="monitoring-pg-stat-all-indexes-view" ==> ok
pg_stat_user_functions, linkend="monitoring-pg-stat-user-functions-view" ==> ok
pg_statio_all_tables, linkend="monitoring-pg-statio-all-tables-view" ==> ok
pg_statio_all_indexes, linkend="monitoring-pg-statio-all-indexes-view" ==> ok
pg_statio_all_sequences,
linkend="monitoring-pg-statio-all-sequences-view" ==> ok
~~~
PSA a patch to make these few changes.
======
Kind Regards,
Peter Smith.
Fujitsu Australia
Attachments:
v1-0001-Change-some-monitoring-linkends-for-consistency.patchapplication/octet-stream; name=v1-0001-Change-some-monitoring-linkends-for-consistency.patchDownload
From eac5887eba9a1b65480f4daae3df05b79ca3d0c3 Mon Sep 17 00:00:00 2001
From: Peter Smith <peter.b.smith@fujitsu.com>
Date: Tue, 3 Oct 2023 13:02:53 +1100
Subject: [PATCH v1] Change some monitoring linkends for consistency
---
doc/src/sgml/logical-replication.sgml | 2 +-
doc/src/sgml/monitoring.sgml | 16 ++++++++--------
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
index fbf8ad6..f07842b 100644
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -1725,7 +1725,7 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
<para>
The monitoring information about subscription is visible in
- <link linkend="monitoring-pg-stat-subscription">
+ <link linkend="monitoring-pg-stat-subscription-view">
<structname>pg_stat_subscription</structname></link>.
This view contains one row for every subscription worker. A subscription
can have zero or more active subscription workers depending on its state.
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 9c4930e..24e66e3 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -336,7 +336,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<row>
<entry><structname>pg_stat_recovery_prefetch</structname><indexterm><primary>pg_stat_recovery_prefetch</primary></indexterm></entry>
<entry>Only one row, showing statistics about blocks prefetched during recovery.
- See <link linkend="monitoring-pg-stat-recovery-prefetch">
+ See <link linkend="monitoring-pg-stat-recovery-prefetch-view">
<structname>pg_stat_recovery_prefetch</structname></link> for details.
</entry>
</row>
@@ -345,7 +345,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<entry><structname>pg_stat_subscription</structname><indexterm><primary>pg_stat_subscription</primary></indexterm></entry>
<entry>At least one row per subscription, showing information about
the subscription workers.
- See <link linkend="monitoring-pg-stat-subscription">
+ See <link linkend="monitoring-pg-stat-subscription-view">
<structname>pg_stat_subscription</structname></link> for details.
</entry>
</row>
@@ -499,7 +499,7 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
<row>
<entry><structname>pg_stat_subscription_stats</structname><indexterm><primary>pg_stat_subscription_stats</primary></indexterm></entry>
<entry>One row per subscription, showing statistics about errors.
- See <link linkend="monitoring-pg-stat-subscription-stats">
+ See <link linkend="monitoring-pg-stat-subscription-stats-view">
<structname>pg_stat_subscription_stats</structname></link> for details.
</entry>
</row>
@@ -1807,7 +1807,7 @@ description | Waiting for a newly initialized WAL file to reach durable storage
</sect2>
- <sect2 id="monitoring-pg-stat-recovery-prefetch">
+ <sect2 id="monitoring-pg-stat-recovery-prefetch-view">
<title><structname>pg_stat_recovery_prefetch</structname></title>
<indexterm>
@@ -1953,14 +1953,14 @@ description | Waiting for a newly initialized WAL file to reach durable storage
</sect2>
- <sect2 id="monitoring-pg-stat-subscription">
+ <sect2 id="monitoring-pg-stat-subscription-view">
<title><structname>pg_stat_subscription</structname></title>
<indexterm>
<primary>pg_stat_subscription</primary>
</indexterm>
- <table id="pg-stat-subscription" xreflabel="pg_stat_subscription">
+ <table id="pg-stat-subscription-view" xreflabel="pg_stat_subscription">
<title><structname>pg_stat_subscription</structname> View</title>
<tgroup cols="1">
<thead>
@@ -2089,7 +2089,7 @@ description | Waiting for a newly initialized WAL file to reach durable storage
</sect2>
- <sect2 id="monitoring-pg-stat-subscription-stats">
+ <sect2 id="monitoring-pg-stat-subscription-stats-view">
<title><structname>pg_stat_subscription_stats</structname></title>
<indexterm>
@@ -2101,7 +2101,7 @@ description | Waiting for a newly initialized WAL file to reach durable storage
one row per subscription.
</para>
- <table id="pg-stat-subscription-stats" xreflabel="pg_stat_subscription_stats">
+ <table id="pg-stat-subscription-stats-view" xreflabel="pg_stat_subscription_stats">
<title><structname>pg_stat_subscription_stats</structname> View</title>
<tgroup cols="1">
<thead>
--
1.8.3.1
On Tue, Oct 03, 2023 at 01:11:15PM +1100, Peter Smith wrote:
I noticed one or two "monitoring" links and linkends that are slightly
inconsistent from all the others.
- <link linkend="monitoring-pg-stat-subscription">
+ <link linkend="monitoring-pg-stat-subscription-view">Is that really worth bothering for the internal link references? This
can create extra backpatching conflicts.
--
Michael
On Tue, Oct 3, 2023 at 6:30 PM Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Oct 03, 2023 at 01:11:15PM +1100, Peter Smith wrote:
I noticed one or two "monitoring" links and linkends that are slightly
inconsistent from all the others.- <link linkend="monitoring-pg-stat-subscription"> + <link linkend="monitoring-pg-stat-subscription-view">Is that really worth bothering for the internal link references?
I preferred 100% consistency instead of 95% consistency. YMMV.
This can create extra backpatching conflicts.
Couldn't the same be said for every patch that fixes a comment typo?
This is like a link typo, so what's the difference?
======
Kind Regards,
Peter Smith.
Fujitsu Australia
On Tue, Oct 3, 2023 at 4:40 PM Peter Smith <smithpb2250@gmail.com> wrote:
On Tue, Oct 3, 2023 at 6:30 PM Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Oct 03, 2023 at 01:11:15PM +1100, Peter Smith wrote:
I noticed one or two "monitoring" links and linkends that are slightly
inconsistent from all the others.- <link linkend="monitoring-pg-stat-subscription"> + <link linkend="monitoring-pg-stat-subscription-view">Is that really worth bothering for the internal link references?
I preferred 100% consistency instead of 95% consistency. YMMV.
This can create extra backpatching conflicts.
Couldn't the same be said for every patch that fixes a comment typo?
This is like a link typo, so what's the difference?
My 2 cents: Comment typos are visible to readers, so more annoying
when seen in isolation, and less likely to have surroundings that
could change in back branches. Consistency would preferred all else
being equal, but then again nothing is wrong with the existing links.
In any case, no one has come out in favor of the patch, so it seems
like it should be rejected unless that changes.
--
John Naylor
On Wed, Nov 8, 2023 at 2:02 PM John Naylor <johncnaylorls@gmail.com> wrote:
My 2 cents: Comment typos are visible to readers, so more annoying
when seen in isolation, and less likely to have surroundings that
could change in back branches. Consistency would preferred all else
being equal, but then again nothing is wrong with the existing links.
In any case, no one has come out in favor of the patch, so it seems
like it should be rejected unless that changes.
This is done.