Hi, thanks for the reply. To be honest I don't think it is better. Previously paragraph about remote_apply was after paragraph about `on` and before remote_write which followed natural order in terms of how strict these parameters are (i.e. how strong are the guarantees they provide). Because of that I think that remote_apply should return to its previous position.
My original concern was about the fact that the difference between `on`, remote_write and remote_apply wasn't perfectly clear. I am not sure if I understand this difference correctly but maybe such a table could be helpful to me and others: +-----------------------------+-------------------------------------------+ | | synchronous_commit | +-----------------------------+-----+--------------+--------------+-------+ | operation on standby server | on | remote_apply | remote_write | local | +-----------------------------+-----+--------------+--------------+-------+ | written to WAL | Yes | Yes | Yes | No | +-----------------------------+-----+--------------+--------------+-------+ | commit transaction | Yes | Yes | No | No | +-----------------------------+-----+--------------+--------------+-------+ | fsync | Yes | No | No | No | +-----------------------------+-----+--------------+--------------+-------+ >From which we can clearly see that only `on` option guarantees fsync, and the only difference between remote_write and remote_apply is the visibility of transaction results to the queries. Also when it comes to the content of your reply, I have few questions: + Finally, when set to <literal>remote_apply</literal>, commits will + wait until replies from the current synchronous standby(s) indicate + they have received the commit record of the transaction and applied + it, so that it has become visible to queries on the standby(s). + This can cause much larger commit delays than previous settings + since it involves WAL replay. 'This can cause much' - What does it mean that it can cause? Under what circumstances it will/won't cause it? "since it involves WAL replay" - What is a WAL replay? Best regards, Kasper Kondzielski pon., 17 sie 2020 o 19:47 Bruce Momjian <br...@momjian.us> napisał(a): > On Fri, Aug 14, 2020 at 01:32:35PM +0000, PG Doc comments form wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/12/runtime-config-wal.html > > Description: > > > > Hello, > > > > First of all I would like to say that PostgreSQL has the best > documentation > > I've ever seen. It is very clear and comprehensive. That's the main > reason > > why I decided to add my little 2 cents and make it even better. > > > > I think that the distinction between first three values of > > synchronous_commit parameter is not clear enough > > ( > https://www.postgresql.org/docs/12/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS > ). > > > > " When set to on, commits will wait until replies from the current > > synchronous standby(s) indicate they have received the commit record of > the > > transaction and flushed it to disk. This ensures the transaction will > not be > > lost unless both the primary and all synchronous standbys suffer > corruption > > of their database storage. When set to remote_apply, commits will wait > until > > replies from the current synchronous standby(s) indicate they have > received > > the commit record of the transaction and applied it, so that it has > become > > visible to queries on the standby(s). When set to remote_write, commits > will > > wait until replies from the current synchronous standby(s) indicate they > > have received the commit record of the transaction and written it out to > > their operating system. This setting is sufficient to ensure data > > preservation even if a standby instance of PostgreSQL were to crash, but > not > > if the standby suffers an operating-system-level crash, since the data > has > > not necessarily reached stable storage on the standby" > > > > The last sentence : "This setting is sufficient to ensure data > preservation > > even if a standby instance..." seems to refer only to the remote_write > > option while in my option it should refer to both remote_write and > > remote_apply options, as the fsync is performed only when > synchronous_commit > > is set to ON. > > > > In other words I think that the documentation should be more clear in > terms > > of which option uses fsync. > > I think this paragraph just has just too complex. I have moved the > mention of remote_apply into its own paragraph, and simplified the > sentences about remote_write. Is this attached patch better? > > -- > Bruce Momjian <br...@momjian.us> https://momjian.us > EnterpriseDB https://enterprisedb.com > > The usefulness of a cup is in its emptiness, Bruce Lee > >
