MIME-Version: 1.0
References: <CALDaNm0gwjY_4HFxvvty01BOT01q_fJLKQ3pWP9=9orqubhjcQ@mail.gmail.com>
 <TYAPR01MB5866C758B1185217950ED13CF5029@TYAPR01MB5866.jpnprd01.prod.outlook.com>
 <CALDaNm0WSo5369pr2eN1obTGBeiJU9cQdF6Ju1sC4hMQNy5BfQ@mail.gmail.com>
 <CAHut+PsAWaETh9VMymbBfMrqiE1KuqMq+wpBg0s7eMzwLATr+w@mail.gmail.com>
 <CALDaNm3GQFVGeKg18wUe1-toXd_80=AW+JOW9KQySVbL8Tz4WA@mail.gmail.com>
 <CAHut+PtRxiQR_4UFLNThg-NNRV447FvwtcR-BvqMzjyMJXKwfw@mail.gmail.com>
 <CALDaNm2ttHxORgvtzd3ZFZe7-uLjfrAX3WSM-Wxf5Et_CVm41Q@mail.gmail.com>
 <CAHut+PvQonJd5epJBM0Yfh1499mL9kTL9a=GrMhvnL6Ok05zqw@mail.gmail.com>
 <CALDaNm3jkotRhKfCqu5CXOf36_yiiW_cYE5=bG=j6N3gOWJkqw@mail.gmail.com>
 <CAExHW5vY9QE0QQyYaCBaMKpvjA2h+AwSk6Y4R9LivK=FnX_OjQ@mail.gmail.com>
 <CAA4eK1+Mtz+StvNNtTg9=9BTq8=pMu-V5i4yWqs=KJUh0Z_L4g@mail.gmail.com> <CALDaNm0SrCcf8tHtpoE6Zjk-xSg4+6eHDRh2NsWBNVxbe7xbtw@mail.gmail.com>
In-Reply-To: <CALDaNm0SrCcf8tHtpoE6Zjk-xSg4+6eHDRh2NsWBNVxbe7xbtw@mail.gmail.com>
From: vignesh C <vignesh21@gmail.com>
Date: Tue, 8 Mar 2022 20:16:24 +0530
Message-ID: <CALDaNm3r7pyisODAL=JzWMX_QKRsnq+jYTLSgMhWFB0fmWzVxg@mail.gmail.com>
Subject: Re: Handle infinite recursion in logical replication setup
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Peter Smith <smithpb2250@gmail.com>, 
	"kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CALDaNm3r7pyisODAL%3DJzWMX_QKRsnq%2BjYTLSgMhWFB0fmWzVxg%40mail.gmail.com>
Precedence: bulk

On Mon, Mar 7, 2022 at 9:57 PM vignesh C <vignesh21@gmail.com> wrote:
>
> On Mon, Mar 7, 2022 at 5:51 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Mon, Mar 7, 2022 at 5:01 PM Ashutosh Bapat
> > <ashutosh.bapat.oss@gmail.com> wrote:
> > >
> > > Hi Vignesh,
> > > I agree with Peter's comment that the changes to
> > > FilterRemoteOriginData() should be part of FilterByOrigin()
> > >
> > > Further, I wonder why "onlylocal_data" is a replication slot's
> > > property. A replication slot tracks the progress of replication and it
> > > may be used by different receivers with different options. I could
> > > start one receiver which wants only local data, say using
> > > "pg_logical_slot_get_changes" and later start another receiver which
> > > fetches all the data starting from where the first receiver left. This
> > > option prevents such flexibility.
> > >
> > > As discussed earlier in the thread, local_only can be property of
> > > publication or subscription, depending upon the use case, but I can't
> > > see any reason that it should be tied to a replication slot.
> > >
> >
> > I thought it should be similar to 'streaming' option of subscription
> > but may be Vignesh has some other reason which makes it different.
>
> Yes, this can be removed from the replication slot. It is my mistake
> that I have made while making the code similar to two-phase, I'm
> working on making the changes for this. I will fix and post an updated
> version for this.

I have made the changes for this, the changes for this are available
in the v3 patch attached at [1].
[1] - https://www.postgresql.org/message-id/CALDaNm0JcV-7iQZhyy3kehnWTy6x%3Dz%2BsX6u6Df%2B%2By8z33pz%2BBw%40mail.gmail.com

Regards,
Vignesh