Re: Request for further clarification on synchronous_commit
| От | Kasper Kondzielski |
|---|---|
| Тема | Re: Request for further clarification on synchronous_commit |
| Дата | |
| Msg-id | CAFv2VPRPmoqpVPTR64jqebQZ6zOzeTCR4xN9c6zXhvaCc4nnNg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Request for further clarification on synchronous_commit (Bruce Momjian <bruce@momjian.us>) |
| Ответы |
Re: Request for further clarification on synchronous_commit
(Bruce Momjian <bruce@momjian.us>)
|
| Список | pgsql-docs |
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.
+ 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@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 <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
В списке pgsql-docs по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: Inaccurate description of UNION/CASE/etc type selection
Следующее
От: Bruce MomjianДата:
Сообщение: Re: Request for further clarification on synchronous_commit