On Wed, Jul 3, 2024 at 5:06 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Wed, Jul 3, 2024 at 4:48 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Wed, Jul 3, 2024 at 4:04 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > >
> > >
> > > What I am saying is that if we are not applying the whole transaction,
> > > it means we are not receiving it either unless we plan to spill it to
> > > a file. If we don't spill it to a file, the network buffer will fill
> > > up very quickly. This issue wouldn't occur if we waited right before
> > > the commit because, by that time, we would have already received all
> > > the data from the network.
> > >
> >
> > We would have received the transaction data but there could be other
> > transactions that need to wait because the apply worker is waiting
> > before the commit.
>
> Yeah, that's a valid point, can parallel apply worker help here?
>
> So, the situation will be the same. We can even
> > decide to spill the data to files if the decision is that we need to
> > wait to avoid network buffer-fill situations. But note that the wait
> > in apply worker has consequences that the subscriber won't be able to
> > confirm the flush position and publisher won't be able to vacuum the
> > dead rows and we won't be remove WAL as well. Last time when we
> > discussed the delay_apply feature, we decided not to proceed because
> > of such issues. This is the reason I proposed a cap on wait time.
>
> Yes, spilling to file or cap on the wait time should help, and as I
> said above maybe a parallel apply worker can also help.
>
It is not clear to me how a parallel apply worker can help in this
case. Can you elaborate on what you have in mind?
--
With Regards,
Amit Kapila.
