On Tue, Oct 8, 2024 at 3:38 PM Amit Kapila wrote:
>
> On Tue, Oct 8, 2024 at 2:25 PM shveta malik wrote:
> >
> > On Mon, Oct 7, 2024 at 4:03 PM vignesh C wrote:
> > >
> >
> > With parallel streaming as default, do you think there is a need to
> > increase the default for 'max_logical_replication
On Mon, 7 Oct 2024 at 11:05, vignesh C wrote:
>
> Hi,
>
> By default, currently streaming of in-progress transactions for
> subscriptions is disabled. All transactions are fully decoded on the
> publisher before being sent to the subscriber. This approach can lead
> to increased latency and reduce
On Tue, Oct 8, 2024 at 2:25 PM shveta malik wrote:
>
> On Mon, Oct 7, 2024 at 4:03 PM vignesh C wrote:
> >
>
> With parallel streaming as default, do you think there is a need to
> increase the default for 'max_logical_replication_workers' as IIUC
> parallel workers are taken from the same pool.
On Mon, Oct 7, 2024 at 4:03 PM vignesh C wrote:
>
With parallel streaming as default, do you think there is a need to
increase the default for 'max_logical_replication_workers' as IIUC
parallel workers are taken from the same pool.
thanks
Shveta
On Mon, 7 Oct 2024 at 12:26, Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Vignesh,
>
> > One key point to consider is that the lock on transaction objects will
> > be held for a longer duration when using streaming in parallel. This
> > occurs because the parallel apply worker initiates the transaction
Dear Vignesh,
> One key point to consider is that the lock on transaction objects will
> be held for a longer duration when using streaming in parallel. This
> occurs because the parallel apply worker initiates the transaction as
> soon as streaming begins, maintaining the lock until the transacti
