Typo in description of replay_lag attribute in pg_stat_replication view
Hello! I have noticed that in description of *flush_lag* in pg_stat_replication view (https://www.postgresql.org/docs/current/monitoring-stats.html#PG-STAT-REPLICATION-VIEW) there exists unknown value of synchronous_commit parameter - *remote_flush*. I think it was meant to use the value *on*. Small patch is attached. -- Regards, Maksim Milyutin diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml index 4164d84..33869be 100644 --- a/doc/src/sgml/monitoring.sgml +++ b/doc/src/sgml/monitoring.sgml @@ -1856,7 +1856,7 @@ SELECT pid, wait_event_type, wait_event FROM pg_stat_activity WHERE wait_event i notification that this standby server has written and flushed it (but not yet applied it). This can be used to gauge the delay that synchronous_commit level - remote_flush incurred while committing if this + on incurred while committing if this server was configured as a synchronous standby.
Re: First SVG graphic
I will create one or more wiki pages where the procedure is described. Everybody can extend this pages or contribute to their discussion sites. The pages will be found in the category 'Documentation' and its subcategory 'SVG' (to be created). The wiki pages are online: https://wiki.postgresql.org/wiki/Category:SVG Kind regards Jürgen Purtz
Re: Return codes for archive and restore commands
> If you were to rewrite those paragraphs or make them more precise, how > would you actually shape your suggestions? I personally quite like the > current formulations, but I am rather used to it to be honest. > -- > Michael Yep, I am for make them more precise. Now this paragraphs describe PostgreSQL and bash behavior for users of PostgreSQL and may be they are good in this. But for a script or application programmer must be described not only behavior of PostgreSQL, but also precisely described the program interface. For instance, aws cli utility, that I used for my archive and restore commands sometimes return 255 code, for instance, in a case of network fault to connect to S3 (object get command). And I was surprised that the PostgreSQL suddenly stoped in such case, there was nothing in documentation about this. So explicitly describing behavior of PostgreSQL in terms of script returning codes will be useful for script programmes.
Re: Typo in description of replay_lag attribute in pg_stat_replication view
On Mon, Dec 03, 2018 at 06:18:30PM +0300, Maksim Milyutin wrote: > I have noticed that in description of *flush_lag* in pg_stat_replication > view > (https://www.postgresql.org/docs/current/monitoring-stats.html#PG-STAT-REPLICATION-VIEW) > there exists unknown value of synchronous_commit parameter - *remote_flush*. > I think it was meant to use the value *on*. Yes, you are right. It should be "on" as "remote_flush" is not a valid value. remote_flush is listed in SyncCommitLevel though, so this makes me wonder if we should also introduce a new value for this purpose available for users. The fix you propose looks good to me. Any opinions from others? -- Michael signature.asc Description: PGP signature
Re: Typo in description of replay_lag attribute in pg_stat_replication view
On Tue, Dec 4, 2018 at 1:18 PM Michael Paquier wrote: > On Mon, Dec 03, 2018 at 06:18:30PM +0300, Maksim Milyutin wrote: > > I have noticed that in description of *flush_lag* in pg_stat_replication > > view > > (https://www.postgresql.org/docs/current/monitoring-stats.html#PG-STAT-REPLICATION-VIEW) > > there exists unknown value of synchronous_commit parameter - *remote_flush*. > > I think it was meant to use the value *on*. > > Yes, you are right. It should be "on" as "remote_flush" is not a valid > value. remote_flush is listed in SyncCommitLevel though, so this makes > me wonder if we should also introduce a new value for this purpose > available for users. The fix you propose looks good to me. Any > opinions from others? +1 for the patch. As for introducing remote_flush as the true name of the level, this was discussed but somehow went off-course and never made it to the finish line: https://www.postgresql.org/message-id/flat/CAEepm%3D3FFaanSS4sugG%2BApzq2tCVjEYCO2wOQBod2d7GWb%3DDvA%40mail.gmail.com -- Thomas Munro http://www.enterprisedb.com
Re: Typo in description of replay_lag attribute in pg_stat_replication view
On Tue, Dec 04, 2018 at 01:28:15PM +1300, Thomas Munro wrote: > On Tue, Dec 4, 2018 at 1:18 PM Michael Paquier wrote: >> Yes, you are right. It should be "on" as "remote_flush" is not a valid >> value. remote_flush is listed in SyncCommitLevel though, so this makes >> me wonder if we should also introduce a new value for this purpose >> available for users. The fix you propose looks good to me. Any >> opinions from others? > > +1 for the patch. Thanks for confirming, Thomas. I'll go apply hopefully tomorrow if nobody has objections. > As for introducing remote_flush as the true name of the level, this > was discussed but somehow went off-course and never made it to the > finish line: > > https://www.postgresql.org/message-id/flat/CAEepm%3D3FFaanSS4sugG%2BApzq2tCVjEYCO2wOQBod2d7GWb%3DDvA%40mail.gmail.com Oh, I forgot this one. We may want to revive that... remote_flush is more meaningful than on, especially since there are more and more possible values for synchronous_commit. -- Michael signature.asc Description: PGP signature
