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

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