Re: releasing ParallelApplyTxnHash when pa_launch_parallel_worker returns NULL
| От | Amit Kapila |
|---|---|
| Тема | Re: releasing ParallelApplyTxnHash when pa_launch_parallel_worker returns NULL |
| Дата | |
| Msg-id | CAA4eK1Lm-0Sh2AA__MRRcYfq8dGaoEk17EcFzmM4YDY-cu5=Hg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: releasing ParallelApplyTxnHash when pa_launch_parallel_worker returns NULL (Ted Yu <yuzhihong@gmail.com>) |
| Список | pgsql-hackers |
On Thu, Jan 12, 2023 at 8:25 AM Ted Yu <yuzhihong@gmail.com> wrote: > On Wed, Jan 11, 2023 at 6:54 PM Amit Kapila <amit.kapila16@gmail.com> wrote: >> >> On Wed, Jan 11, 2023 at 9:31 AM Ted Yu <yuzhihong@gmail.com> wrote: >> > >> > On Tue, Jan 10, 2023 at 7:55 PM houzj.fnst@fujitsu.com <houzj.fnst@fujitsu.com> wrote: >> >> >> >> On Wednesday, January 11, 2023 10:21 AM Ted Yu <yuzhihong@gmail.com> wrote: >> >> > /* First time through, initialize parallel apply worker state hashtable. */ >> >> > if (!ParallelApplyTxnHash) >> >> > >> >> > I think it would be better if `ParallelApplyTxnHash` is created by the first >> >> > successful parallel apply worker. >> >> >> >> Thanks for the suggestion. But I am not sure if it's worth to changing the >> >> order here, because It will only optimize the case where user enable parallel >> >> apply but never get an available worker which should be rare. And in such a >> >> case, it'd be better to increase the number of workers or disable the parallel mode. >> >> >> > >> > >> > I think even though the chance is rare, we shouldn't leak resource. >> > >> >> But that is true iff we are never able to start the worker. Anyway, I >> think it is probably fine either way but we can change it as per your >> suggestion to make it more robust and probably for the code clarity >> sake. I'll push this tomorrow unless someone thinks otherwise. >> Pushed. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: