On Wed, Jul 3, 2024 at 5:06 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Wed, Jul 3, 2024 at 4:48 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Wed, Jul 3, 2024 at 4:04 PM Dilip Kumar <dilipbal...@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.
