Re: releasing ParallelApplyTxnHash when pa_launch_parallel_worker returns NULL

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: Ted Yu <yuzhihong@gmail.com>
Cc: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-01-13T09:44:12Z
Lists: 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.



Commits

  1. Avoid creating parallel apply state hash table unless required.