On Mon, Dec 26, 2022 at 2:12 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Fri, Dec 23, 2022 at 9:16 PM Takamichi Osumi (Fujitsu)
> <osumi.takamichi@fujitsu.com> wrote:
> >
>
> 4.
>
> + * Although the delay is applied in BEGIN messages, streamed transactions
> + * apply the delay in a STREAM COMMIT message. That's ok because no
> + * changes have been applied yet (apply_spooled_messages() will do it).
> + * The STREAM START message would be a natural choice for this delay but
> + * there is no commit time yet (it will be available when the in-progress
> + * transaction finishes), hence, it was not possible to apply a delay at
> + * that time.
> + */
> + maybe_delay_apply(commit_data.committime);
>
> I am wondering how this will interact with the parallel apply worker
> where we do not spool the data in file? How are we going to get the
> commit time of the transaction without applying the changes?
>
There is no sane way to do this. So, I think these features won't work
together, we can disable parallelism when this is active. Considering
that parallel apply is to speed up the transactions apply and this
feature is to slow down the apply, so even if they don't work together
that should be okay. Does that make sense?
--
With Regards,
Amit Kapila.