public inbox for [email protected]  

help / color / mirror / Atom feed

From: Heikki Linnakangas <[email protected]>
To: David Geier <[email protected]>
To: Tom Lane <[email protected]>
To: Peter Eisentraut <[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: Wed, 15 Apr 2026 14:06:14 +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]>
	<[email protected]>
	<[email protected]>

On 14/04/2026 10:02, David Geier wrote:
>> 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.

This was briefly discussed when PointerGetDatum() was changed from a 
macro to a static inline function [1]. On that email, Peter pointed out 
that the compiler was doing the same deduction that Coverity did now, 
i.e. that if you pass the Datum returned by PointerGetDatum(&foo) to a 
function, it cannot change *foo. I'm surprised we dismissed that worry 
so quickly. If the compiler optimizes based on that assumption, you can 
get incorrect code.

Three alternative fixes were discussed on that thread. Here's a fourth 
one that I think is better;

#define PointerGetDatum(X) \
	((Datum) (uintptr_t) (true ? (X) : NULL))

I found this trick with the dummy conditional expression at [2]. It 
always evaluates to just (X), but it has the effect that you get a 
compiler error if (X) is not a pointer.


[1] 
https://www.postgresql.org/message-id/812568f2-ff1d-ebd9-aee6-e00d8f2e0fb6%40enterprisedb.com

[2] See "TO_VOID_PTR_EXPR()" at 
https://medium.com/@pauljlucas/generic-in-c-d7ab47e3b5ab

> Ah, that could be it.
> Is there a way for me to run Coverity on a patch to test that out?

Not really I'm afraid. I can commit a fix and we'll see if it helps the 
next time that Coverity runs (= Sunday).

> Which Coverity CI do we actually use? Is it this one here [1]?
> 
> [1] https://scan.coverity.com/projects/209?

Yeah, that's the one, but only the security team has access.

- 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], [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