On Mon, Dec 26, 2022 at 7:37 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> 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.
>
BTW, the blocking problem with this patch is to deal with shutdown as
discussed in the thread [1]. In short, the problem is that at
shutdown, we wait for walsender to send all pending data and ensure
all data is flushed in the remote node. But, if the other node is
waiting due to a time-delayed apply then shutdown won't be successful.
It would be really great if you can let us know your thoughts in the
thread [1] as that can help to move this work forward.
[1] -
https://www.postgresql.org/message-id/TYAPR01MB586668E50FC2447AD7F92491F5E89%40TYAPR01MB5866.jpnprd01.prod.outlook.com
--
With Regards,
Amit Kapila.
