Re: Reduce build times of pg_trgm GIN indexes

On 12/04/2026 21:05, Tom Lane wrote:
> 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?

I didn't do it for performance, but because I find the function easier
to read that way. We could change it back.

It's a pretty scary thought that a compiler might misoptimize that
though. In the same function we have 'nullFlags', too, as a local
variable, even before this commit. Not sure why Coverity doesn't
complain about that.

> /*
> * PointerGetDatum
> * Returns datum representation for a pointer.
> */
> static inline Datum
> PointerGetDatum(const void *X)
> {
> return (Datum) (uintptr_t) X;
> }

Hmm, is that 'const' incorrect? This function doesn't modify *X, but the
resulting address will be used to modify it. Maybe changing it to
non-const "void *X" would give Coverity a hint.

- Heikki