Horton

Re: Allow logical replication to copy tables in binary format

Peter Smith <smithpb2250@gmail.com>

View thread
From: Peter Smith <smithpb2250@gmail.com>
To: Melih Mutlu <m.melihmutlu@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, "shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>, "Takamichi Osumi (Fujitsu)" <osumi.takamichi@fujitsu.com>, Euler Taveira <euler@eulerto.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>
Date: 2023-03-02T01:57:09Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow logical replication to copy tables in binary format.

  2. Common function for percent placeholder replacement

  3. Doc: add XML ID attributes to <sectN> and <varlistentry> tags.

  4. Re-order disable_on_error in tab-complete.

  5. Make subscription tests pass with log_error_verbosity=verbose

  6. Weaken type-OID-matching checks in array_recv and record_recv.

  7. Allow logical replication to transfer data in binary format.

On Thu, Mar 2, 2023 at 5:10 AM Melih Mutlu <m.melihmutlu@gmail.com> wrote:
>
> Hi,
>
> Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.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.
>
>>

IIUC most people seem to be coming down in favour of there being a
single unified option (the existing 'binary==true/false) which would
apply to both the COPY and the data replication parts.

I also agree
- Yes, it is simpler.
- Yes, there are various workarounds in case the COPY part failed

But, AFAICT the main question remains unanswered -- Are we happy to
break existing applications already using binary=true. E.g. I think
there might be cases where applications are working *only* because
their binary=true is internally (and probably unbeknownst to the user)
reverting to text. So if we unified everything under one 'binary'
option then binary=true will force COPY binary so now some previously
working applications will get COPY errors requiring workarounds. Is
that acceptable?

TBH I am not sure anymore if the complications justify the patch.

It seems we have to choose from 2 bad choices:
- separate options = this works but would be more confusing for the user
- unified option = this would be simpler and faster, but risks
breaking existing applications currently using 'binary=true'

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