Re: Allow logical replication to copy tables in binary format - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Allow logical replication to copy tables in binary format
Date
Msg-id CAA4eK1LSqMpqD4rSJSgDg=zX+P_iiz17r=Un+DRZcOY91Wp_2w@mail.gmail.com
Whole thread Raw
In response to Re: Allow logical replication to copy tables in binary format  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: Allow logical replication to copy tables in binary format  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
Re: Allow logical replication to copy tables in binary format  (Peter Smith <smithpb2250@gmail.com>)
List pgsql-hackers
On Thu, Mar 2, 2023 at 7:27 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> 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.
Itcan 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?
>

I think one can look at this from another angle also where users would
be expecting that when binary = true and copy_data = true, all the
data transferred between publisher and subscriber should be in binary
format. Users have a workaround to set binary=true only after the
initial sync. Also, if at all, the behaviour change would be after
major version upgrade which shouldn't be a problem.

> 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'
>

I would prefer a unified option as apart from other things you and
others mentioned that will be less of a maintenance burden in the
future.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Time delayed LR (WAS Re: logical replication restrictions)
Next
From: Michael Paquier
Date:
Subject: Re: add PROCESS_MAIN to VACUUM