Re: Parallel CREATE INDEX for GIN indexes

On 3/9/25 17:38, Tom Lane wrote:
> Tomas Vondra <tomas@vondra.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