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

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