Re: releasing ParallelApplyTxnHash when pa_launch_parallel_worker returns NULL
Ted Yu <yuzhihong@gmail.com>
From: Ted Yu <yuzhihong@gmail.com>
To: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>
Cc: "akapila@postgresql.org" <akapila@postgresql.org>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-01-11T04:01:15Z
Lists: pgsql-hackers
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. > > Best Regards, > Hou zj > I think even though the chance is rare, we shouldn't leak resource. The `ParallelApplyTxnHash` shouldn't be created if there is no single apply worker.
Commits
-
Avoid creating parallel apply state hash table unless required.
- dca8b01f5f1f 16.0 landed