| From: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, 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-14 07:02:10 |
| Message-ID: | 77cc23dd-ac53-4bb9-9e90-0019c9ff58df@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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.
Ah, that could be it.
Is there a way for me to run Coverity on a patch to test that out?
Which Coverity CI do we actually use? Is it this one here [1]?
[1] https://scan.coverity.com/projects/209?
--
David Geier
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Evgeny Voropaev | 2026-04-14 07:08:24 | Re: Compress prune/freeze records with Delta Frame of Reference algorithm |
| Previous Message | Nisha Moond | 2026-04-14 06:30:12 | Support EXCEPT for TABLES IN SCHEMA publications |