RE: Time delayed LR (WAS Re: logical replication restrictions)

Hi, Andres-san

On Tuesday, February 14, 2023 1:47 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2023-02-11 05:44:47 +0000, Takamichi Osumi (Fujitsu) wrote:
> > On Saturday, February 11, 2023 11:10 AM Andres Freund
> <andres(at)anarazel(dot)de> wrote:
> > > Has there been any discussion about whether this is actually best
> > > implemented on the client side? You could alternatively implement it
> > > on the sender.
> > >
> > > That'd have quite a few advantages, I think - you e.g. wouldn't
> > > remove the ability to *receive* and send feedback messages. We'd
> > > not end up filling up the network buffer with data that we'll not process
> anytime soon.
> > Thanks for your comments !
> >
> > We have discussed about the publisher side idea around here [1] but,
> > we chose the current direction. Kindly have a look at the discussion.
> >
> > If we apply the delay on the publisher, then it can lead to extra
> > delay where we don't need to apply.
> > The current proposed approach can take other loads or factors
> > (network, busyness of the publisher, etc) into account because it
> > calculates the required delay on the subscriber.
>
> I don't think it's OK to just loose the ability to read / reply to keepalive
> messages.
>
> I think as-is we seriously consider to just reject the feature, adding too much
> complexity, without corresponding gain.
Thanks for your comments !

Could you please tell us about your concern a bit more?

The keepalive/reply messages are currently used for two purposes,
(a) send the updated wrte/flush/apply locations; (b) avoid timeouts incase of idle times.
Both the cases shouldn't be impacted with this time-delayed LR patch because during the delay there won't
be any progress and to avoid timeouts, we allow to send the alive message during the delay.
This is just we would like to clarify the issue you have in mind.

OTOH, if we want to implement the functionality on publisher-side,
I think we need to first consider the interface.
We can think of two options (a) Have it as a subscription parameter as the patch has now and
then pass it as an option to the publisher which it will use to delay;
(b) Have it defined on publisher-side, say via GUC or some other way.
The basic idea could be that while processing commit record (in DecodeCommit),
we can somehow check the value of delay and then use it there to delay sending the xact.
Also, during delay, we need to somehow send the keepalive and process replies,
probably via a new callback or by some existing callback.
We also need to handle in-progress and 2PC xacts in a similar way.
For the former, probably we would need to apply the delay before sending the first stream.
Could you please share what you feel on this direction as well ?

Best Regards,
Takamichi Osumi