Re: Allow logical replication to copy tables in binary format

Поиск
Список
Период
Сортировка
От Bharath Rupireddy
Тема Re: Allow logical replication to copy tables in binary format
Дата
Msg-id CALj2ACUN=1GKTdRG-fH4PrE-i6cAxXQd=COh6_bXYiUsP2=HMQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Allow logical replication to copy tables in binary format  (Melih Mutlu <m.melihmutlu@gmail.com>)
Ответы Re: Allow logical replication to copy tables in binary format
Список pgsql-hackers
On Tue, Feb 28, 2023 at 1:22 AM Melih Mutlu <m.melihmutlu@gmail.com> wrote:
>
> Hi,
>
> Thanks for all of your reviews!
>
> So, I made some changes in the v10 according to your comments.

Thanks. Some quick comments on v10:

1.
+      <para>
+       If true, initial data synchronization will be performed in binary format
+      </para></entry>
It's not just the initial table sync right? The table sync can happen
at any other point of time when ALTER SUBSCRIPTION ... REFRESH
PUBLICATION WITH (copy = true) is run.
How about - "If true, the subscriber requests publication for
pre-existing data in binary format"?

2.
+          Specifies whether pre-existing data on the publisher will be copied
+          to the subscriber in binary format. The default is
<literal>false</literal>.
+          Binary format is very data type specific, it will not allow copying
+          between different column types as opposed to text format. Note that
+          if this option is enabled, all data types which will be copied during
+          the initial synchronization should have binary send and
receive functions.
+          If this option is disabled, data format for the initial
synchronization
+          will be text.
Perhaps, this should cover the recommended cases for enabling this new
option - something like below (may not need to have exact wording, but
the recommended cases?):

"It is recommended to enable this option only when 1) the column data
types have appropriate binary send/receive functions, 2) not
replicating between different major versions or different platforms,
3) both publisher and subscriber tables have the exact same column
types (not when replicating from smallint to int or numeric to int8
and so on), 4) both publisher and subscriber supports COPY with binary
option, otherwise the table copy can fail."

3. I think the newly added tests must verify if the binary COPY is
picked up when enabled. Perhaps, looking at the publisher's server log
for 'COPY ... WITH BINARY format'? Maybe it's an overkill, otherwise,
we have no way of testing that the option took effect.

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: WIN32 pg_import_system_collations
Следующее
От: "Drouvot, Bertrand"
Дата:
Сообщение: Re: Add shared buffer hits to pg_stat_io