Re: Reduce build times of pg_trgm GIN indexes - Mailing list pgsql-hackers

Heikki Linnakangas <hlinnaka@iki.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