Re: Parallel CREATE INDEX for GIN indexes

On 3/9/25 17:38, Tom Lane wrote:
> Tomas Vondra <tomas(at)vondra(dot)me> writes:
>> I pushed the two smaller parts today.
>
> Coverity is a little unhappy about this business in
> _gin_begin_parallel:
>
> bool leaderparticipates = true;
> ...
> #ifdef DISABLE_LEADER_PARTICIPATION
> leaderparticipates = false;
> #endif
> ...
> scantuplesortstates = leaderparticipates ? request + 1 : request;
>
> It says
>
>>>> CID 1644203: Possible Control flow issues (DEADCODE)
>>>> Execution cannot reach the expression "request" inside this statement: "scantuplesortstates = (lead...".
> 924 scantuplesortstates = leaderparticipates ? request + 1 : request;
>
> If this were just temporary code I'd let it pass, but I see nothing
> replacing this logic in the follow-up patches, so I think we ought
> to do something to shut it up.
>
> It's not complaining about the later bits like
>
> if (leaderparticipates)
> ginleader->nparticipanttuplesorts++;
>
> (perhaps because there's no dead code there?) So one idea is
>
> scantuplesortstates = request;
> if (leaderparticipates)
> scantuplesortstates++;
>
> which would look more like the other code anyway.
>

I don't mind doing it differently, but this code is just a copy from
_bt_begin_parallel. So how come coverity does not complain about that?
Or is that whitelisted?

thanks

--
Tomas Vondra