From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <hlinnaka@iki.fi>
cc: David Geier <geidav.pg@gmail.com>,
        Matthias van de Meent <boekewurm+postgres@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Reduce build times of pg_trgm GIN indexes
In-reply-to: <6439c655-e281-409d-b884-6586750d5820@iki.fi>
References: <5d366878-2007-4d31-861e-19294b7a583b@gmail.com>
 <9ac3931a-180e-4283-a7a8-05eb66099206@iki.fi>
 <e5dd01c6-c469-405d-aea2-feca0b2dc34d@gmail.com>
 <2e11134f-02c3-43da-8c39-fb520a1a251d@iki.fi>
 <66620ec7-0f81-4813-9cf1-b901a56efcc3@gmail.com>
 <CAEze2WiUL9idZBbuUN+MuWqr6DcPr_-C91E9MTx=H62Xx5fHaQ@mail.gmail.com>
 <ef8782c9-68b7-4915-9f79-497765a8e205@gmail.com>
 <a90ebbbd-0d77-49c7-b222-3dbffa4e3b14@gmail.com>
 <2a76b5ef-4b12-4023-93a1-eed6e64968f3@gmail.com>
 <6439c655-e281-409d-b884-6586750d5820@iki.fi>
Comments: In-reply-to Heikki Linnakangas <hlinnaka@iki.fi>
	message dated "Tue, 07 Apr 2026 14:27:40 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <342011.1776017102.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 12 Apr 2026 14:05:02 -0400
Message-ID: <342012.1776017102@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/342012.1776017102%40sss.pgh.pa.us>
Precedence: bulk

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: 4=
95             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 t=
hem from
492     	 * the array here, and after deduplication, put back one NULL ent=
ry to
493     	 * represent them all.
494     	 */
>>>     CID 1691468:         Control flow issues  (DEADCODE)
>>>     Execution cannot reach this statement: "hasNull =3D false;".
495     	hasNull =3D false;
496     	if (nullFlags)
497     	{
498     		int32		numNonNulls =3D 0;
499     =

500     		for (int32 i =3D 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