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

On Wed, Feb 1, 2023 at 3:10 PM shiy(dot)fnst(at)fujitsu(dot)com
<shiy(dot)fnst(at)fujitsu(dot)com> wrote:
>
> On Mon, Jan 30, 2023 6:05 PM Takamichi Osumi (Fujitsu) <osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
> >
> > Kindly have a look at the attached v25.
> >
>
> Thanks for your patch. Here are some comments.
>
> 1.
> + /*
> + * The min_apply_delay parameter is ignored until all tablesync workers
> + * have reached READY state. This is because if we allowed the delay
> + * during the catchup phase, then once we reached the limit of tablesync
> + * workers it would impose a delay for each subsequent worker. That would
> + * cause initial table synchronization completion to take a long time.
> + */
> + if (!AllTablesyncsReady())
> + return;
>
> I saw that the new parameter becomes effective after all tables are in ready
> state, because the apply worker can't set the state to catchup during the delay.
> But can we call process_syncing_tables() in the while-loop of
> maybe_apply_delay()? Then the tablesync can finish without delay. If we can't do
> so, it might be better to add some comments for it.
>

I think the point here is that if the apply worker is ahead of
tablesync worker then to complete the catch-up, tablesync worker needs
to apply additional transactions, and delaying during that time will
cause initial table synchronization completion to take a long time. I
am not sure how much more details can be added to the existing
comments.

--
With Regards,
Amit Kapila.