public inbox for [email protected]
help / color / mirror / Atom feedFrom: Amit Kapila <[email protected]>
To: Peter Smith <[email protected]>
Cc: vignesh C <[email protected]>
Cc: Ashutosh Bapat <[email protected]>
Cc: [email protected] <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Handle infinite recursion in logical replication setup
Date: Tue, 8 Mar 2022 13:24:47 +0530
Message-ID: <CAA4eK1JVK01phoyFMporFWANFZdk0Uv8wU2Qckb=Gi8UnXgM2A@mail.gmail.com> (raw)
In-Reply-To: <CAHut+PucgbMkNGq1iD2=muGh61HeDbJufLbLjFsQAQsOJu=dpw@mail.gmail.com>
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>
<CAHut+Pu7=cmy7cw8Oc1mss-3NqSMHvw2UxW-APqW9-sFK1OhEA@mail.gmail.com>
<CAA4eK1Lk=v=EtTzsPcsjkrAY1F9uOLJdmNq1uRvvagdE=OyDxw@mail.gmail.com>
<CAHut+PucgbMkNGq1iD2=muGh61HeDbJufLbLjFsQAQsOJu=dpw@mail.gmail.com>
On Tue, Mar 8, 2022 at 12:17 PM Peter Smith <[email protected]> wrote:
>
> On Tue, Mar 8, 2022 at 4:21 PM Amit Kapila <[email protected]> wrote:
> >
> > On Tue, Mar 8, 2022 at 10:31 AM Peter Smith <[email protected]> wrote:
> > >
> > > IIUC the new option may be implemented subscriber-side and/or
> > > publisher-side and/or both, and the subscriber-side option may be
> > > "enhanced" in future to prevent cycles. And probably there are more
> > > features I don't know about or that have not yet been thought of.
> > >
> > > ~~
> > >
> > > Even if the plan is only to implement just one part now and then add
> > > more later, I think there still should be some consideration for what
> > > you expect all possible future options to look like, because that may
> > > affect current implementation choices.
> > >
> > > The point is:
> > >
> > > - we should take care so don't accidentally end up with an option that
> > > turned out to be inconsistent looking on the subscriber-side /
> > > publisher-side.
> > >
> > > - we should try to avoid accidentally painting ourselves into a corner
> > > (e.g. stuck with a boolean option that cannot be enhanced later on)
> > >
> >
> > Agreed. I think it is important to see we shouldn't do something which
> > is not extendable in future or paint us in the corner. But, as of now,
> > with the current proposal, the main thing we should consider is
> > whether exposing the boolean option is okay or shall we do something
> > different so that we can extend it later to specific origin ids?
> >
>
> I was wondering, assuming later there is an enhancement to detect and
> prevent cycles using origin ids, then what really is the purpose of
> the option?
>
We can't use origin ids during the initial sync as we can't
differentiate between data from local or remote node. Also, how will
we distinguish between different origins? AFAIU, all the changes
applied on any particular node use the same origin.
> I can imagine if a cycle happens should probably log some one-time
> WARNING (just to bring it to the user's attention in case it was
> caused by some accidental misconfiguration) but apart from that why
> would this need to be an option at all - i.e. is there a use-case
> where a user would NOT want to prevent a recursive error?
>
I think there will be plenty of such setups where there won't be a
need for any such option like where users won't need bi-directional
replication for the same table.
--
With Regards,
Amit Kapila.
view thread (16+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Handle infinite recursion in logical replication setup
In-Reply-To: <CAA4eK1JVK01phoyFMporFWANFZdk0Uv8wU2Qckb=Gi8UnXgM2A@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox