Re: Reduce build times of pg_trgm GIN indexes

Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> Pushed 0001 as commit 6f5ad00ab7.

This commit has caused Coverity to start complaining that
most of ginExtractEntries() is unreachable:

*** CID 1691468: Control flow issues (DEADCODE)
/srv/coverity/git/pgsql-git/postgresql/src/backend/access/gin/ginutil.c: 495 in ginExtractEntries()
489 /*
490 * Scan the items for any NULLs. All NULLs are considered equal, so we
491 * just need to check and remember if there are any. We remove them from
492 * the array here, and after deduplication, put back one NULL entry to
493 * represent them all.
494 */
>>> CID 1691468: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "hasNull = false;".
495 hasNull = false;
496 if (nullFlags)
497 {
498 int32 numNonNulls = 0;
499
500 for (int32 i = 0; i < nentries; i++)

Evidently, it does not realize that the extractValueFn() can change
nentries from its initial value of zero. I wouldn't be too surprised
if that's related to our casting of the pointer to uintptr_t --- that
may cause it to not see the passed pointer as a potential reference
mechanism.

I would just write that off as Coverity not being smart enough, except
that I'm worried that some compiler might make a similar deduction and
break the function completely. Was the switch to a local variable
for nentries really a useful win performance-wise?

regards, tom lane