Re: Allow logical replication to copy tables in binary format
От | Amit Kapila |
---|---|
Тема | Re: Allow logical replication to copy tables in binary format |
Дата | |
Msg-id | CAA4eK1LSqMpqD4rSJSgDg=zX+P_iiz17r=Un+DRZcOY91Wp_2w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Allow logical replication to copy tables in binary format (Peter Smith <smithpb2250@gmail.com>) |
Ответы |
Re: Allow logical replication to copy tables in binary format
Re: Allow logical replication to copy tables in binary format |
Список | 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 по дате отправления: