Horton
Menu

Re: Parallel CREATE INDEX for GIN indexes

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas@vondra.me>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-03-09T16:38:49Z
Lists: pgsql-hackers 
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.

			regards, tom lane

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Exercise parallel GIN builds in regression tests

  2. Lookup the correct ordering for parallel GIN builds

  3. Fix memory leak in _gin_parallel_merge

  4. Enforce memory limit during parallel GIN builds

  5. Compress TID lists when writing GIN tuples to disk

  6. Allow parallel CREATE INDEX for GIN indexes