Re: Parallel CREATE INDEX for GIN indexes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Parallel CREATE INDEX for GIN indexes
Date: 2025-03-09 16:38:49
Message-ID: 291432.1741538329@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-03-09 16:47:34 Re: BackgroundPsql swallowing errors on windows
Previous Message Tom Lane 2025-03-09 15:48:05 Re: Clarification on Role Access Rights to Table Indexes