Re: Allow logical replication to copy tables in binary format

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "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>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: Allow logical replication to copy tables in binary format
Date: 2023-03-03 00:32:33
Message-ID: CAHut+Pu5wMuxX9v8OVPgtzWaLMP8CHN106Ps+r41frA4BRBOPQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 2, 2023 at 4:00 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, Mar 2, 2023 at 7:27 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >
...
> > 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.

My concern was mostly just about the potential to break the behaviour
of existing binary=true applications in some edge cases.

If you are happy that doing so shouldn't be a problem, then I am also
+1 to use the unified option.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-03-03 00:37:27 Re: Normalization of utility queries in pg_stat_statements
Previous Message Andres Freund 2023-03-03 00:29:07 Re: Add the ability to limit the amount of memory that can be allocated to backends.