Feedback-ID: ie0a040ee:Fastmail
Message-ID: <aa908216-6ed6-4d19-b63c-a13441aeae4c@eisentraut.org>
Date: Wed, 15 Apr 2026 21:12:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Reduce build times of pg_trgm GIN indexes
To: Heikki Linnakangas <hlinnaka@iki.fi>, David Geier <geidav.pg@gmail.com>,
 Tom Lane <tgl@sss.pgh.pa.us>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
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>
 <342012.1776017102@sss.pgh.pa.us>
 <8f3fab0e-02e1-4948-9683-224fe54e30ae@iki.fi>
 <77cc23dd-ac53-4bb9-9e90-0019c9ff58df@gmail.com>
 <195097d6-64cd-4adb-b8a3-1d86ae31c411@iki.fi>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <195097d6-64cd-4adb-b8a3-1d86ae31c411@iki.fi>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/aa908216-6ed6-4d19-b63c-a13441aeae4c%40eisentraut.org>
Precedence: bulk

On 15.04.26 13:06, Heikki Linnakangas wrote:
> 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.

I don't think this is in evidence.  AFAICT, it's just Coverity that is 
complaining here, which is its right, but the code is not incorrect.