Re: [HACKERS] Adding in docs the meaning of pg_stat_replication.sync_state

[Fujii Masao]

On Tue, Dec 6, 2016 at 4:54 PM, Michael Paquier
 wrote:
> On Tue, Dec 6, 2016 at 4:38 PM, Fujii Masao  wrote:
>> I changed the order of descriptions of the walsender state in
>> intuitive one rather than alphabetical one. Also I enhanced
>> the description of "potential" state.
>>
>> Could you review the latest patch?
>
> Fine for me. The additions in high-availability.sgml are a good idea.

Pushed. Thanks!

Regards,

-- 
Fujii Masao


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Adding in docs the meaning of pg_stat_replication.sync_state

[Michael Paquier]

On Tue, Dec 6, 2016 at 4:38 PM, Fujii Masao  wrote:
> I changed the order of descriptions of the walsender state in
> intuitive one rather than alphabetical one. Also I enhanced
> the description of "potential" state.
>
> Could you review the latest patch?

Fine for me. The additions in high-availability.sgml are a good idea.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Adding in docs the meaning of pg_stat_replication.sync_state

[Fujii Masao]

On Tue, Dec 6, 2016 at 2:13 PM, Michael Paquier
 wrote:
> On Tue, Dec 6, 2016 at 1:54 PM, Fujii Masao  wrote:
>> +   backup: The WAL sender is sending a backup.
>>
>> Seems it's better to use "This WAL sender" rather than "The WAL sender"
>> like the descriptions of other fields.
>>
>> There are two descriptions of "streaming" value. You need to remove
>> either of them.
>>
>> +   streaming: The WAL sender is catching up with the
>> +   primary.
>>
>> "walsender is catching up with the primary" sounds a bit strange to me.
>> What about "This WAL sender's connected standby server is catching up
>> with the primary"?
>>
>> +   streaming: The WAL sender has caught up with the
>> +   primary and is streaming changes.
>>
>> Same as above.
>
> Agreed with all that. Attached is an updated version.

Thanks for updating the patch! Attached is the updated version of the patch.

I changed the order of descriptions of the walsender state in
intuitive one rather than alphabetical one. Also I enhanced
the description of "potential" state.

Could you review the latest patch?

Regards,

-- 
Fujii Masao
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
***
*** 1161,1166  synchronous_standby_names = '2 (s1, s2, s3)'
--- 1161,1170 
  s2 fails. s4 is an asynchronous standby since
  its name is not in the list.
 
+
+ The synchronous states of standby servers can be viewed using
+ the pg_stat_replication view.
+
 
  
 
***
*** 1235,1240  synchronous_standby_names = '2 (s1, s2, s3)'
--- 1239,1246 
  will increase according to the length of time the standby has been down.
  The standby is only able to become a synchronous standby
  once it has reached streaming state.
+ This state can be viewed using
+ the pg_stat_replication view.
 
  
 
*** a/doc/src/sgml/monitoring.sgml
--- b/doc/src/sgml/monitoring.sgml
***
*** 1357,1363  SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
  
   state
   text
!  Current WAL sender state
  
  
   sent_location
--- 1357,1389 
  
   state
   text
!  Current WAL sender state.
!Possible values are:
!
!  
!   
!startup: This WAL sender is starting up.
!   
!  
!  
!   
!catchup: This WAL sender's connected standby is
!catching up with the primary.
!   
!  
!  
!   
!streaming: This WAL sender is streaming changes
!after its connected standby server has caught up with the primary.
!   
!  
!  
!   
!backup: This WAL sender is sending a backup.
!   
!  
!
!  
  
  
   sent_location
***
*** 1391,1397  SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
  
   sync_state
   text
!  Synchronous state of this standby server
  
 
 
--- 1417,1444 
  
   sync_state
   text
!  Synchronous state of this standby server.
!Possible values are:
!
!  
!   
!async: This standby server is asynchronous.
!   
!  
!  
!   
!potential: This standby server is now asynchronous,
!but can potentially become synchronous if one of current
!synchronous ones fails.
!   
!  
!  
!   
!sync: This standby server is synchronous.
!   
!  
!
!  
  
 
 

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Adding in docs the meaning of pg_stat_replication.sync_state

[Michael Paquier]

On Tue, Dec 6, 2016 at 1:54 PM, Fujii Masao  wrote:
> +   backup: The WAL sender is sending a backup.
>
> Seems it's better to use "This WAL sender" rather than "The WAL sender"
> like the descriptions of other fields.
>
> There are two descriptions of "streaming" value. You need to remove
> either of them.
>
> +   streaming: The WAL sender is catching up with the
> +   primary.
>
> "walsender is catching up with the primary" sounds a bit strange to me.
> What about "This WAL sender's connected standby server is catching up
> with the primary"?
>
> +   streaming: The WAL sender has caught up with the
> +   primary and is streaming changes.
>
> Same as above.

Agreed with all that. Attached is an updated version.
-- 
Michael
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 02dab879d9..bf30a9ee08 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -1357,7 +1357,33 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
 
  state
  text
- Current WAL sender state
+ Current WAL sender state.
+   Possible values are:
+   
+ 
+  
+   backup: This WAL sender is sending a backup.
+  
+ 
+ 
+  
+   catchup: This WAL sender's connected standby is
+   catching up with the primary.
+  
+ 
+ 
+  
+   startup: This WAL sender is starting.
+  
+ 
+ 
+  
+   streaming: This WAL sender's connected standby
+   server has caught up with the primary and is streaming changes.
+  
+ 
+   
+ 
 
 
  sent_location
@@ -1391,7 +1417,27 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i
 
  sync_state
  text
- Synchronous state of this standby server
+ Synchronous state of this standby server.
+   Possible values are:
+   
+ 
+  
+   async: Standby server is asynchronous.
+  
+ 
+ 
+  
+   potential: Standby server can potentially become
+   synchronous.
+  
+ 
+ 
+  
+   sync: Standby server is synchronous.
+  
+ 
+   
+ 
 



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Adding in docs the meaning of pg_stat_replication.sync_state

[Fujii Masao]

On Fri, Nov 11, 2016 at 10:03 PM, Michael Paquier
 wrote:
> On Thu, Nov 10, 2016 at 10:35 PM, Fujii Masao  wrote:
>> On Wed, Nov 9, 2016 at 2:33 PM, Michael Paquier
>>  wrote:
>>> Hi all,
>>>
>>> The documentation does not explain at all what means "sync" or "async"
>>> on pg_stat_replication.
>>
>> "potential" state also should be explained?
>
> Of course.
>
>>> The paragraph "Planning for high availability"
>>> mentions "catchup" and "streaming", but it does not say that users can
>>> refer to it directly in pg_stat_replication.
>>>
>>> Thoughts about the patch attached to add a couple of sentences in
>>> "Planning for high availability"? We could as well mention it directly
>>> in the page of pg_stat_replication but this information seems more
>>> suited if located in the HA section.
>>
>> Yeah, I think it's better to mention them even in pg_stat_replication page.
>
> OK, so I have done things this way. What do you think? At the same
> time it would be good to mention all the possible field values in
> "state", aka streaming, catchup, etc so I added that as well.

Thanks for the patch!

+   backup: The WAL sender is sending a backup.

Seems it's better to use "This WAL sender" rather than "The WAL sender"
like the descriptions of other fields.

There are two descriptions of "streaming" value. You need to remove
either of them.

+   streaming: The WAL sender is catching up with the
+   primary.

"walsender is catching up with the primary" sounds a bit strange to me.
What about "This WAL sender's connected standby server is catching up
with the primary"?

+   streaming: The WAL sender has caught up with the
+   primary and is streaming changes.

Same as above.

Regards,

-- 
Fujii Masao


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Adding in docs the meaning of pg_stat_replication.sync_state

[Michael Paquier]

On Thu, Nov 10, 2016 at 10:35 PM, Fujii Masao  wrote:
> On Wed, Nov 9, 2016 at 2:33 PM, Michael Paquier
>  wrote:
>> Hi all,
>>
>> The documentation does not explain at all what means "sync" or "async"
>> on pg_stat_replication.
>
> "potential" state also should be explained?

Of course.

>> The paragraph "Planning for high availability"
>> mentions "catchup" and "streaming", but it does not say that users can
>> refer to it directly in pg_stat_replication.
>>
>> Thoughts about the patch attached to add a couple of sentences in
>> "Planning for high availability"? We could as well mention it directly
>> in the page of pg_stat_replication but this information seems more
>> suited if located in the HA section.
>
> Yeah, I think it's better to mention them even in pg_stat_replication page.

OK, so I have done things this way. What do you think? At the same
time it would be good to mention all the possible field values in
"state", aka streaming, catchup, etc so I added that as well.
-- 
Michael


sync-state-docs.patch
Description: binary/octet-stream

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Adding in docs the meaning of pg_stat_replication.sync_state

[Fujii Masao]

On Wed, Nov 9, 2016 at 2:33 PM, Michael Paquier
 wrote:
> Hi all,
>
> The documentation does not explain at all what means "sync" or "async"
> on pg_stat_replication.

"potential" state also should be explained?

> The paragraph "Planning for high availability"
> mentions "catchup" and "streaming", but it does not say that users can
> refer to it directly in pg_stat_replication.
>
> Thoughts about the patch attached to add a couple of sentences in
> "Planning for high availability"? We could as well mention it directly
> in the page of pg_stat_replication but this information seems more
> suited if located in the HA section.

Yeah, I think it's better to mention them even in pg_stat_replication page.

Regards,

-- 
Fujii Masao


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Adding in docs the meaning of pg_stat_replication.sync_state

[Michael Paquier]

Hi all,

The documentation does not explain at all what means "sync" or "async"
on pg_stat_replication. The paragraph "Planning for high availability"
mentions "catchup" and "streaming", but it does not say that users can
refer to it directly in pg_stat_replication.

Thoughts about the patch attached to add a couple of sentences in
"Planning for high availability"? We could as well mention it directly
in the page of pg_stat_replication but this information seems more
suited if located in the HA section.

Thanks,
-- 
Michael
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 5bedaf2..5ef6aa9 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1235,6 +1235,8 @@ synchronous_standby_names = '2 (s1, s2, s3)'
 will increase according to the length of time the standby has been down.
 The standby is only able to become a synchronous standby
 once it has reached streaming state.
+This is directly reported by the system view
+pg_stat_replication with the field state.

 

@@ -1259,6 +1261,12 @@ synchronous_standby_names = '2 (s1, s2, s3)'

 

+Asynchronous standbys are reported as async in the system
+view pg_stat_replication with the field
+sync_state, and synchronous standbys as sync.
+   
+
+   
 If the primary is isolated from remaining standby servers you should
 fail over to the best candidate of those other remaining standby servers.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers