Re: releasing ParallelApplyTxnHash when pa_launch_parallel_worker returns NULL
Ted Yu <yuzhihong@gmail.com>
From: Ted Yu <yuzhihong@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, "akapila@postgresql.org" <akapila@postgresql.org>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-01-12T02:55:18Z
Lists: pgsql-hackers
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. > > -- > With Regards, > Amit Kapila. > Thanks Amit for the confirmation. Cheers
Commits
-
Avoid creating parallel apply state hash table unless required.
- dca8b01f5f1f 16.0 landed