Re: Request for further clarification on synchronous_commit

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 <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> https://momjian.us
> EnterpriseDB https://enterprisedb.com
>
> The usefulness of a cup is in its emptiness, Bruce Lee
>
>