Re: Perform streaming logical transactions by background workers and parallel apply

Поиск
Список
Период
Сортировка
От Peter Smith
Тема Re: Perform streaming logical transactions by background workers and parallel apply
Дата
Msg-id CAHut+PtM-uG6q3XtJxXdV7_PiYGcMs0FiR3mfSbn1BQ-3BGfuA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Perform streaming logical transactions by background workers and parallel apply  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Perform streaming logical transactions by background workers and parallel apply
Список pgsql-hackers
Some minor review comments for v91-0001

======
doc/src/sgml/config.sgml

1.
        <para>
-        Allows streaming or serializing changes immediately in
logical decoding.
-        The allowed values of <varname>logical_replication_mode</varname> are
-        <literal>buffered</literal> and <literal>immediate</literal>. When set
-        to <literal>immediate</literal>, stream each change if
+        The allowed values are <literal>buffered</literal> and
+        <literal>immediate</literal>. The default is
<literal>buffered</literal>.
+        This parameter is intended to be used to test logical decoding and
+        replication of large transactions for which otherwise we need
to generate
+        the changes till <varname>logical_decoding_work_mem</varname> is
+        reached.  The effect of <varname>logical_replication_mode</varname> is
+        different for the publisher and subscriber:
+       </para>

The "for which otherwise..." part is only relevant for the
publisher-side. So it seemed slightly strange to give the reason why
to use the GUC for one side but not the other side.

Maybe we can just to remove that "for which otherwise..." part, since
the logical_decoding_work_mem gets mentioned later in the "On the
publisher side,..." paragraph anyway.

~~~

2.
        <para>
-        This parameter is intended to be used to test logical decoding and
-        replication of large transactions for which otherwise we need to
-        generate the changes till <varname>logical_decoding_work_mem</varname>
-        is reached.
+        On the subscriber side, if the <literal>streaming</literal>
option is set to
+        <literal>parallel</literal>,
<varname>logical_replication_mode</varname>
+        can be used to direct the leader apply worker to send changes to the
+        shared memory queue or to serialize changes to the file.  When set to
+        <literal>buffered</literal>, the leader sends changes to parallel apply
+        workers via a shared memory queue.  When set to
+        <literal>immediate</literal>, the leader serializes all
changes to files
+        and notifies the parallel apply workers to read and apply them at the
+        end of the transaction.
        </para>

"or serialize changes to the file." --> "or serialize all changes to
files." (just to use same wording as later in this same paragraph, and
also same wording as the GUC hint text).

------
Kind Regards,
Peter Smith.
Fujitsu Australia



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: pg_dump versus hash partitioning
Следующее
От: David Rowley
Дата:
Сообщение: Re: pg_dump versus hash partitioning