public inbox for [email protected]  

help / color / mirror / Atom feed

From: Heikki Linnakangas <[email protected]>
To: Tom Lane <[email protected]>
Cc: David Geier <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Reduce build times of pg_trgm GIN indexes
Date: Mon, 13 Apr 2026 19:14:23 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAEze2WiUL9idZBbuUN+MuWqr6DcPr_-C91E9MTx=H62Xx5fHaQ@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On 12/04/2026 21:05, Tom Lane wrote:
> Heikki Linnakangas <[email protected]> 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

view thread (31+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Reduce build times of pg_trgm GIN indexes
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox