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

At Wed, 25 Jan 2023 12:30:19 +0530, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote in
> On Wed, Jan 25, 2023 at 11:57 AM Kyotaro Horiguchi
> <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> >
> > At Tue, 24 Jan 2023 12:19:04 +0000, "Takamichi Osumi (Fujitsu)" <osumi(dot)takamichi(at)fujitsu(dot)com> wrote in
> > > Attached the patch v20 that has incorporated all comments so far.
> >
> ...
> >
> >
> > + in which case no additional wait is necessary. If the system clocks
> > + on publisher and subscriber are not synchronized, this may lead to
> > + apply changes earlier than expected, but this is not a major issue
> > + because this parameter is typically much larger than the time
> > + deviations between servers. Note that if this parameter is set to a
> >
> > This doesn't seem to fit our documentation. It is not our business
> > whether a certain amount deviation is critical or not. How about
> > somethig like the following?
> >
>
> But we have a similar description for 'recovery_min_apply_delay' [1].
> See "...If the system clocks on primary and standby are not
> synchronized, this may lead to recovery applying records earlier than
> expected; but that is not a major issue because useful settings of
> this parameter are much larger than typical time deviations between
> servers."

Mmmm. I thought that we might be able to gather the description
(including other common descriptions, if any), but I didn't find an
appropreate place..

Okay. I agree to the current description. Thanks for the kind
explanation.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center