| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, David Geier <geidav(dot)pg(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Reduce build times of pg_trgm GIN indexes |
| Date: | 2026-04-15 19:12:51 |
| Message-ID: | aa908216-6ed6-4d19-b63c-a13441aeae4c@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2026-04-15 19:17:12 | Re: Add bms_offset_members() function for bitshifting Bitmapsets |
| Previous Message | Tom Lane | 2026-04-15 18:49:06 | Re: Add errdetail() with PID and UID about source of termination signal |