On Wed, Feb 1, 2023 at 3:10 PM shiy.f...@fujitsu.com <shiy.f...@fujitsu.com> wrote: > > On Mon, Jan 30, 2023 6:05 PM Takamichi Osumi (Fujitsu) > <osumi.takami...@fujitsu.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.
