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
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 |