On Mon, Sep 8, 2025 at 3:10 PM Ashutosh Bapat <[email protected]> wrote: > > On Sat, Sep 6, 2025 at 10:33 AM Dilip Kumar <[email protected]> wrote: > > On Wed, Aug 13, 2025 at 4:17 PM Zhijie Hou (Fujitsu) > > <[email protected]> wrote: > > > > > > Here is the initial POC patch for this idea. > > > > > > > > > If no parallel apply worker is available, the leader will apply the > > > transaction > > > independently. > > > > This type of strategy might be suitable in scenarios where users > > cannot supply more workers due to resource limitations. However, on > > high-end machines, it is more efficient to let the leader act solely > > as a message transmitter and allow the apply workers to handle all > > apply tasks. This could be a configurable parameter, determining > > whether the leader also participates in applying changes. I believe > > this should not be the default strategy; in fact, the default should > > be for the leader to act purely as a transmitter. > > In case the leader encounters an error while applying a transaction, > it will have to be restarted. Would that restart all the parallel > apply workers? That will be another (minor) risk when letting the > leader apply transactions. The probability of hitting an error while > applying a transaction is more than when just transmitting messages. >
I think we have to anyway (irrespective of whether it applies changes by itself or not) let leader restart in this case because otherwise, we may not get the failed transaction again. Also, if one of the pa exits without completing the transaction, it is important to let other pa's also exit otherwise dependency calculation can go wrong. There could be some cases where we could let some pa complete its current ongoing transaction if it is independent of other transactions and has received all its changes. -- With Regards, Amit Kapila.
