Re: Allow logical replication to copy tables in binary format

From: Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: "shiy(dot)fnst(at)fujitsu(dot)com" <shiy(dot)fnst(at)fujitsu(dot)com>, "Takamichi Osumi (Fujitsu)" <osumi(dot)takamichi(at)fujitsu(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: Allow logical replication to copy tables in binary format
Date: 2023-03-01 18:09:44
Message-ID: CAGPVpCToH1vT3WZ6rFxYMVAcHn-hb9kRb7wpqaTn_r7h1Ms3jw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Hayato Kuroda (Fujitsu) <kuroda(dot)hayato(at)fujitsu(dot)com>, 1 Mar 2023 Çar, 18:40
tarihinde şunu yazdı:

> Dear Melih,
>
> If we do not have to treat the case Shi pointed out[1] as code-level, I
> agreed to
> same option binary because it is simpler.

How is this an issue if we let the binary option do binary copy and not an
issue if we have a separate copy_binary option?
You can easily have the similar errors when you set copy_binary=true if a
type is missing binary send/receive functions.
And also, as Amit mentioned, the same issue can easily be avoided if
binary=false until the initial sync is done. It can be set to true later.

> I read the use-cases addressed by Bharath[2]
> and I cannot find advantage for case 1 and 3 expect the case that binary
> functions
> are not implemented.
>

Note that case 3 is already how it works on HEAD. Its advantages, as you
already mentioned, is when some types are missing the binary functions.
I think that's why case 3 should be allowed even if a new option is added
or not.

Previously I said that the combination of "copy_format = binary" and
> "copy_data = false"
> seemed strange[3], but this approach could solve it and other related ones
> automatically.
>

I think it is quite similar to the case where binary=true and
enabled=false. In that case, the format is set but the subscription does
not replicate anything. And this is allowed.
copy_binary=true and copy_data=false combination also sets the copy format
but does not copy anything. Even if any table will not be copied at that
moment, tables which might be added later might need to be copied (by ALTER
SUBSCRIPTION). And setting the copy format beforehand can be useful in such
cases.

> I think we should add description to doc that it is more likely happen to
> fail
> the initial copy user should enable binary format after synchronization if
> tables have original datatype.
>

I tried to explain when binary copy can cause failures in the doc. What
exactly do you think is missing?

Best,
--
Melih Mutlu
Microsoft

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2023-03-01 18:09:53 Re: add PROCESS_MAIN to VACUUM
Previous Message Melanie Plageman 2023-03-01 17:51:16 Add pg_walinspect function with block info columns