Re: Perform streaming logical transactions by background workers and parallel apply - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Perform streaming logical transactions by background workers and parallel apply
Date
Msg-id CAA4eK1J=9m-VNRMHCqeG8jpX0CTn3Ciad2o4H-ogrZMDJ3tn4w@mail.gmail.com
Whole thread Raw
In response to RE: Perform streaming logical transactions by background workers and parallel apply  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Responses Re: Perform streaming logical transactions by background workers and parallel apply  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Wed, Dec 7, 2022 at 6:33 PM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.com> wrote:
>
> On Wednesday, December 7, 2022 7:51 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
>
> > ---
> > When max_parallel_apply_workers_per_subscription is changed to a value
> > lower than the number of parallel worker running at that time, do we
> > need to stop extra workers?
>
> I think we can do this, like adding a check in the main loop of leader worker, and
> check every time after reloading the conf. OTOH, we will also stop the worker after
> finishing a transaction, so I am slightly not sure do we need to add another check logic here.
> But I am fine to add it if you think it would be better.
>

I think this is tricky because it is possible that all active workers
are busy with long-running transactions, so, I think stopping them
doesn't make sense. I think as long as we are freeing them after use
it seems okay to me. OTOH, each time after finishing the transaction,
we can stop the workers, if the workers in the free pool exceed
'max_parallel_apply_workers_per_subscription'. I don't know if it is
worth.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Isaac Morland
Date:
Subject: Re: add \dpS to psql
Next
From: Amit Kapila
Date:
Subject: Re: Avoid streaming the transaction which are skipped (in corner cases)