RE: Allow logical replication to copy tables in binary format
От | osumi.takamichi@fujitsu.com |
---|---|
Тема | RE: Allow logical replication to copy tables in binary format |
Дата | |
Msg-id | TYCPR01MB8373367B78B034CECA9E070EED4E9@TYCPR01MB8373.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Allow logical replication to copy tables in binary format (Melih Mutlu <m.melihmutlu@gmail.com>) |
Список | pgsql-hackers |
Hi Few more minor comments. On Tuesday, August 16, 2022 2:04 AM Melih Mutlu <m.melihmutlu@gmail.com> wrote: > > > My main concern is to break a scenario that was previously working (14 > -> 15) but after a subscriber upgrade > it won't (14 -> 16). > > Fair concern. Some cases that might break the logical replication with version > upgrade would be: ... > 3- Copying in binary format would work with the same schemas. Currently, > logical replication does not require the exact same schemas in publisher and > subscriber. > This is an additional restriction that comes with the COPY command. > > If a logical replication has been set up with different schemas and subscription > is created with the binary option, then yes this would break things. > This restriction can be clearly stated and wouldn't be unexpected though. > > I'm also okay with allowing binary copy only for v16 or later, if you think it would > be safer and no one disagrees with that. > What are your thoughts? I agree with the direction to support binary copy for v16 and later. IIUC, the binary format replication with different data types fails even during apply phase on HEAD. I thought that means, the upgrade concern only applies to a scenario that the user executes only initial table synchronizations between the publisher and subscriber and doesn't replicate any data at apply phase after that. I would say this isn't a valid scenario and your proposal makes sense. Best Regards, Takamichi Osumi
В списке pgsql-hackers по дате отправления: