public inbox for [email protected]
help / color / mirror / Atom feedFrom: Kyotaro Horiguchi <[email protected]>
To: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Subject: Re: Time delayed LR (WAS Re: logical replication restrictions)
Date: Thu, 15 Dec 2022 14:52:32 +0900 (JST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA4eK1JmayanpdQaJnabYLcK8qnsp7YoOnWzd3n0qUzzQfxmkw@mail.gmail.com>
References: <CAA4eK1LhE0iBtJ76u+efRkSB_n7t_bsR=ZVjrxVGfLoQ4JyuqA@mail.gmail.com>
<[email protected]>
<CAA4eK1JmayanpdQaJnabYLcK8qnsp7YoOnWzd3n0qUzzQfxmkw@mail.gmail.com>
At Thu, 15 Dec 2022 10:29:17 +0530, Amit Kapila <[email protected]> wrote in
> On Thu, Dec 15, 2022 at 10:11 AM Kyotaro Horiguchi
> <[email protected]> wrote:
> >
> > At Thu, 15 Dec 2022 09:18:55 +0530, Amit Kapila <[email protected]> wrote in
> > > On Thu, Dec 15, 2022 at 7:22 AM Kyotaro Horiguchi
> > > <[email protected]> wrote:
> > > subscriber was busy enough that it doesn't need to add an additional
> > > delay before applying a particular transaction(s) but adding a delay
> > > to such a transaction on the publisher will actually make it take much
> > > longer to reflect than expected. We probably need to name this
> >
> > Isn't the name min_apply_delay implying the same behavior? Even though
> > the delay time will be a bit prolonged.
> >
>
> Sorry, I don't understand what you intend to say in this point. In
> above, I mean that the currently proposed patch won't have such a
> problem but if we apply delay on publisher the problem can happen.
Are you saing about the sender-side delay lets the whole transaction
(if it have not streamed out) stay on the sender side? If so... yeah,
I agree that it is undesirable.
> > > parameter as min_send_delay if we want to do what you are saying and
> > > then I don't know if it serves the actual need and also it will be
> > > different from what we do in physical standby.
> >
> > In the first place phisical and logical replication works differently
> > and the mechanism to delaying "apply" differs even in the current
> > state in terms of logrep delay choking stream.
> >
>
> I think the first preference is to make it work in a similar way (as
> much as possible) to how this parameter works in physical standby and
> if that is not at all possible then we may consider other approaches.
I uderstood that. However, still I think choking the stream on the
receiver-side alone is kind of ugly since it is breaking the protocol
assumption, that is, the in-band maintenance packets are processed in
a on-time manner on the peer under normal operation (even though
involving some delays for some natural reasons). In this regard, I
inclined to be in favor of Kuroda-san'sproposal..
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
view thread (93+ 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], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Time delayed LR (WAS Re: logical replication restrictions)
In-Reply-To: <[email protected]>
* 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