Re: Parallel Apply - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Parallel Apply
Date
Msg-id CAExHW5v61BTFQ-129AbJTjBzGsvoJHVb56nyyYtaeBuKWuh92Q@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Apply  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
On Sat, Sep 6, 2025 at 10:33 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> On Wed, Aug 13, 2025 at 4:17 PM Zhijie Hou (Fujitsu)
> <houzj.fnst@fujitsu.com> 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.

--
Best Wishes,
Ashutosh Bapat



pgsql-hackers by date:

Previous
From: Nitin Motiani
Date:
Subject: [PATCH] Accept connections post recovery without waiting for RemoveOldXlogFiles
Next
From: Zsolt Parragi
Date:
Subject: Re: OAuth client code doesn't work with Google OAuth