On Mon, Dec 26, 2022 at 2:44 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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.
Yeah, there is no sane way to do it.
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?
Yes, this makes sense.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
