public inbox for [email protected]  
help / color / mirror / Atom feed
Fix links to pg_stat_replication and definition of checkpoint_warning GUC
2+ messages / 2 participants
[nested] [flat]

* Fix links to pg_stat_replication and definition of checkpoint_warning GUC
@ 2018-02-19 10:25 Maksim Milyutin <[email protected]>
  2018-03-03 19:25 ` Re: Fix links to pg_stat_replication and definition of checkpoint_warning GUC Peter Eisentraut <[email protected]>
  0 siblings, 1 reply; 2+ messages in thread

From: Maksim Milyutin @ 2018-02-19 10:25 UTC (permalink / raw)
  To: [email protected]

Hello everyone!


I have noticed that in documentation for PG versions before 11devel some 
*pg_stat_replication/* /links refer to *collected statistic views* table 
instead of itself definition. Fixes for version 10.2 are gathered in 
fix_pg_stat_replication_links_doc.patch


Also I am confused by the definition of *checkpoint_warning* parameter, 
namely the phrase "caused by the filling of checkpoint segment files". I 
think the word "checkpoint" is unnecessary here. I tried to rephrase 
this definition in fix_checkpoint_warning_definition_doc.patch.


-- 
Regards,
Maksim Milyutin



Attachments:

  [text/x-patch] fix_checkpoint_warning_definition_doc.patch (782B, 3-fix_checkpoint_warning_definition_doc.patch)
  download | inline diff:
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 8f55026..2472b2d 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2751,8 +2751,8 @@ include_dir 'conf.d'
       <listitem>
        <para>
         Write a message to the server log if checkpoints caused by
-        the filling of checkpoint segment files happen closer together
-        than this many seconds (which suggests that
+        the achieving maximum amount of filled segment files happen closer
+        together than this many seconds (which suggests that
         <varname>max_wal_size</> ought to be raised).  The default is
         30 seconds (<literal>30s</>).  Zero disables the warning.
         No warnings will be generated if <varname>checkpoint_timeout</varname>


  [text/x-patch] fix_pg_stat_replication_links_doc.patch (3.8K, 4-fix_pg_stat_replication_links_doc.patch)
  download | inline diff:
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 8f55026..64a28f5 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3096,7 +3096,7 @@ include_dir 'conf.d'
         in this list, and
         that are both currently connected and streaming data in real-time
         (as shown by a state of <literal>streaming</literal> in the
-        <link linkend="monitoring-stats-views-table">
+        <link linkend="pg-stat-replication-view">
         <literal>pg_stat_replication</></link> view).
         Specifying more than one synchronous standby can allow for very high
         availability and protection against data loss.
@@ -3344,7 +3344,7 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
        Specifies the minimum frequency for the WAL receiver
        process on the standby to send information about replication progress
        to the primary or upstream standby, where it can be seen using the
-       <link linkend="monitoring-stats-views-table">
+       <link linkend="pg-stat-replication-view">
        <literal>pg_stat_replication</></link> view.  The standby will report
        the last write-ahead log location it has written, the last position it
        has flushed to disk, and the last position it has applied.
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 6c54fbd..2737b31 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -890,7 +890,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
     </para>
     <para>
      You can retrieve a list of WAL sender processes via the
-     <link linkend="monitoring-stats-views-table">
+     <link linkend="pg-stat-replication-view">
      <literal>pg_stat_replication</></link> view. Large differences between
      <function>pg_current_wal_lsn</> and the view's <literal>sent_lsn</> field
      might indicate that the master server is under heavy load, while
diff --git a/doc/src/sgml/release-10.sgml b/doc/src/sgml/release-10.sgml
index dbb1a9b..7ef7025 100644
--- a/doc/src/sgml/release-10.sgml
+++ b/doc/src/sgml/release-10.sgml
@@ -3416,7 +3416,7 @@ Branch: REL_10_STABLE [5159626af] 2017-11-03 14:14:16 -0400
 -->
       <para>
        Add columns to <link
-       linkend="monitoring-stats-views-table"><structname>pg_stat_replication</structname></link>
+       linkend="pg-stat-replication-view"><structname>pg_stat_replication</structname></link>
        to report replication delay times (Thomas Munro)
       </para>
 
diff --git a/doc/src/sgml/release-9.1.sgml b/doc/src/sgml/release-9.1.sgml
index 0454f84..b8cb7e3 100644
--- a/doc/src/sgml/release-9.1.sgml
+++ b/doc/src/sgml/release-9.1.sgml
@@ -9667,7 +9667,7 @@ Branch: REL9_0_STABLE [9d6af7367] 2015-08-15 11:02:34 -0400
       <listitem>
        <para>
         Add system view <link
-        linkend="monitoring-stats-views-table"><structname>pg_stat_replication</></link>
+        linkend="pg-stat-replication-view"><structname>pg_stat_replication</></link>
         which displays activity of <acronym>WAL</> sender processes (Itagaki
         Takahiro, Simon Riggs)
        </para>
diff --git a/doc/src/sgml/release-9.5.sgml b/doc/src/sgml/release-9.5.sgml
index 56de825..6ccb6f5 100644
--- a/doc/src/sgml/release-9.5.sgml
+++ b/doc/src/sgml/release-9.5.sgml
@@ -6725,7 +6725,7 @@ max_wal_size = (3 * checkpoint_segments) * 16MB
 -->
      <para>
       The <link
-      linkend="monitoring-stats-views-table"><structname>pg_stat_replication</structname></link>
+      linkend="pg-stat-replication-view"><structname>pg_stat_replication</structname></link>
       system view's <structfield>sent</structfield> field is now NULL, not zero, when
       it has no valid value (Magnus Hagander)
      </para>


^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: Fix links to pg_stat_replication and definition of checkpoint_warning GUC
  2018-02-19 10:25 Fix links to pg_stat_replication and definition of checkpoint_warning GUC Maksim Milyutin <[email protected]>
@ 2018-03-03 19:25 ` Peter Eisentraut <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: Peter Eisentraut @ 2018-03-03 19:25 UTC (permalink / raw)
  To: Maksim Milyutin <[email protected]>; [email protected]

On 2/19/18 05:25, Maksim Milyutin wrote:
> I have noticed that in documentation for PG versions before 11devel some
> *pg_stat_replication/* /links refer to *collected statistic views* table
> instead of itself definition. Fixes for version 10.2 are gathered in
> fix_pg_stat_replication_links_doc.patch

This was due to a reorganization of the documentation in 9.5, so the
links became outdated.  Fixed.

> Also I am confused by the definition of *checkpoint_warning* parameter,
> namely the phrase "caused by the filling of checkpoint segment files". I
> think the word "checkpoint" is unnecessary here. I tried to rephrase
> this definition in fix_checkpoint_warning_definition_doc.patch.

This was more appropriate when the related parameter was called
checkpoint_segments, but now it indeed seems confusing.  Also fixed.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services





^ permalink  raw  reply  [nested|flat] 2+ messages in thread


end of thread, other threads:[~2018-03-03 19:25 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-02-19 10:25 Fix links to pg_stat_replication and definition of checkpoint_warning GUC Maksim Milyutin <[email protected]>
2018-03-03 19:25 ` Peter Eisentraut <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox