Fix links to pg_stat_replication and definition of checkpoint_warning GUC

2018-02-19 Thread Maksim Milyutin 

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

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'
   

 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
 max_wal_size ought to be raised).  The default is
 30 seconds (30s).  Zero disables the warning.
 No warnings will be generated if checkpoint_timeout
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 streaming in the
-
+
 pg_stat_replication view).
 Specifying more than one synchronous standby can allow for very high
 availability and protection against data loss.
@@ -3344,7 +3344,7 @@ ANY num_sync ( 
+   
pg_stat_replication 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'
 
 
  You can retrieve a list of WAL sender processes via the
- 
+ 
  pg_stat_replication view. Large differences between
  pg_current_wal_lsn and the view's 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
 -->
   
Add columns to pg_stat_replication
+   linkend="pg-stat-replication-view">pg_stat_replication
to report replication delay times (Thomas Munro)
   
 
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
   

 Add system view pg_stat_replication
+linkend="pg-stat-replication-view">pg_stat_replication
 which displays activity of WAL sender processes (Itagaki
 Takahiro, Simon Riggs)

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
 -->
  
   The pg_stat_replication
+  linkend="pg-stat-replication-view">pg_stat_replication
   system view's sent field is now NULL, not zero, when
   it has no valid value (Magnus Hagander)

docu bug?

2018-02-19 Thread PG Doc comments form 
The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/9.6/static/continuous-archiving.html
Description:

Seems to need a persistent connection:


25.3.3.1. Making a non-exclusive low level backup
...
The connection calling pg_start_backup must be maintained until the end of
the backup, or the backup will be automatically aborted.
...



The sample works with a NON-persistent connection (psql -c):


25.3.6.1. Standalone Hot Backups
...  touch /var/lib/pgsql/backup_in_progress
psql -c "select pg_start_backup('hot_backup');"
tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
psql -c "select pg_stop_backup();"
rm /var/lib/pgsql/backup_in_progress
tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/
...

Re: docu bug?

2018-02-19 Thread Salvador Jacinto 
POR FAVOR TRADUZIR

Em 19/02/2018 9:55 AM, "PG Doc comments form" 
escreveu:

> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/9.6/static/continuous-archiving.html
> Description:
>
> Seems to need a persistent connection:
>
> 
> 25.3.3.1. Making a non-exclusive low level backup
> ...
> The connection calling pg_start_backup must be maintained until the end of
> the backup, or the backup will be automatically aborted.
> ...
> 
>
>
> The sample works with a NON-persistent connection (psql -c):
>
> 
> 25.3.6.1. Standalone Hot Backups
> ...  touch /var/lib/pgsql/backup_in_progress
> psql -c "select pg_start_backup('hot_backup');"
> tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
> psql -c "select pg_stop_backup();"
> rm /var/lib/pgsql/backup_in_progress
> tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/
> ...
> 
>

Re: docu bug?

2018-02-19 Thread Michael Paquier 
On Mon, Feb 19, 2018 at 01:54:24PM +, PG Doc comments form wrote:
> The sample works with a NON-persistent connection (psql -c):
> 
> 
> 25.3.6.1. Standalone Hot Backups
> ...  touch /var/lib/pgsql/backup_in_progress
> psql -c "select pg_start_backup('hot_backup');"
> tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
> psql -c "select pg_stop_backup();"
> rm /var/lib/pgsql/backup_in_progress
> tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/
> ...
> 

This uses the set of exclusive backup APIs, so with non-persistent
connections the backup can be correctly completed.  Non-exclusive
backups can be defined using 'false' as third argument of 
pg_start_backup() and first argument of pg_stop_backup().  Note that for
pg_start_backup you would also need to define the second boolean
argument to decide if a checkpoint should be immediately taken or not.
So you would have basically the following flow on a persistem
connection:
=# SELECT pg_start_backup('my_backup', true_or_false, false);
-- keep connection alive and do stuff.
=# SELECT pg_stop_backup(false);

Do you think that the section "Tips and Examples" should mention
that an exclusive backup method is used for this example?  This may
reduce the confusion.
--
Michael


signature.asc
Description: PGP signature