Re: Perform streaming logical transactions by background workers and parallel apply
От | Amit Kapila |
---|---|
Тема | Re: Perform streaming logical transactions by background workers and parallel apply |
Дата | |
Msg-id | CAA4eK1J=9m-VNRMHCqeG8jpX0CTn3Ciad2o4H-ogrZMDJ3tn4w@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Perform streaming logical transactions by background workers and parallel apply ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>) |
Ответы |
Re: Perform streaming logical transactions by background workers and parallel apply
|
Список | 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 по дате отправления: