On Mon, Dec 26, 2022 at 2:44 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Mon, Dec 26, 2022 at 2:12 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > > > On Fri, Dec 23, 2022 at 9:16 PM Takamichi Osumi (Fujitsu) > > <osumi.takami...@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
