Re: Handle infinite recursion in logical replication setup
От | vignesh C |
---|---|
Тема | Re: Handle infinite recursion in logical replication setup |
Дата | |
Msg-id | CALDaNm1Baadm0Ce4iVpeufRdt2ic10qp_J4JXSL+2pbdY6hQsw@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Handle infinite recursion in logical replication setup ("kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>) |
Список | pgsql-hackers |
On Tue, Mar 1, 2022 at 4:12 PM kuroda.hayato@fujitsu.com <kuroda.hayato@fujitsu.com> wrote: > > Hi Vignesh, > > > In logical replication, currently Walsender sends the data that is > > generated locally and the data that are replicated from other > > instances. This results in infinite recursion in circular logical > > replication setup. > > Thank you for good explanation. I understand that this fix can be used > for a bidirectional replication. Once these issues are resolved, it can be used for bi-directional logical replication. > > Here there are two problems for the user: a) incremental > > synchronization of table sending both local data and replicated data > > by walsender b) Table synchronization of table using copy command > > sending both local data and replicated data > > So you wanted to solve these two problem and currently focused on > the first one, right? We can check one by one. Yes. > > For the first problem "Incremental synchronization of table by > > Walsender" can be solved by: > > Currently the locally generated data does not have replication origin > > associated and the data that has originated from another instance will > > have a replication origin associated. We could use this information to > > differentiate locally generated data and replicated data and send only > > the locally generated data. This "only_local" could be provided as an > > option while subscription is created: > > ex: CREATE SUBSCRIPTION sub1 CONNECTION 'dbname =postgres port=5433' > > PUBLICATION pub1 with (only_local = on); > > Sounds good, but I cannot distinguish whether the assumption will keep. Replication origin is created by the apply worker and it will be used for all the transactions received from the walsender. I feel the replication origin will be present always. > I played with your patch, but it could not be applied to current master. > I tested from bd74c40 and I confirmed infinite loop was not appeared. I will post an updated version for this soon. > local_only could not be set from ALTER SUBSCRIPTION command. > Is it expected? I wanted to get the opinion from others too just to make sure the approach is right. I will fix this including the documentation, test, etc in the later versions. Regards, Vignesh
В списке pgsql-hackers по дате отправления: