Re: releasing ParallelApplyTxnHash when pa_launch_parallel_worker returns NULL - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: releasing ParallelApplyTxnHash when pa_launch_parallel_worker returns NULL
Date
Msg-id CAA4eK1KM4pmyh6CZ-HnqP--Eeqd68u2uy1gDKtBM4KyYkgmrmg@mail.gmail.com
Whole thread Raw
In response to Re: releasing ParallelApplyTxnHash when pa_launch_parallel_worker returns NULL  (Ted Yu <yuzhihong@gmail.com>)
Responses Re: releasing ParallelApplyTxnHash when pa_launch_parallel_worker returns NULL
List pgsql-hackers
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.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: on placeholder entries in view rule action query's range table
Next
From: Ted Yu
Date:
Subject: Re: releasing ParallelApplyTxnHash when pa_launch_parallel_worker returns NULL