PARANOIA_LEVEL

Paul Ramsey pramsey at cleverelephant.ca
Thu Jan 18 15:49:47 PST 2024


I feel like the most “standard” thing to do would be to convert them all to assert()s and then have a

—enable-assert 

option. And then we can add other asserts to our heart’s content without having to know about this weird option Dave invented back in 2004.

P

> On Jan 18, 2024, at 2:25 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> 
> There are only a handful of uses (grep for "PARANOIA_LEVEL >”) and except for one they are all testing > 0. So I think an on/off, or potentially just strip them out. I never flip them on, on purpose, and have never assumed anything other than that it was always off (imagine my surprise to find it on).
> 
> P
> 
>> On Jan 18, 2024, at 2:23 PM, Sandro Santilli <strk at kbt.io> wrote:
>> 
>> On Thu, Jan 18, 2024 at 04:25:55PM -0500, Regina Obe wrote:
>>>> On Thu, Jan 18, 2024 at 08:13:04AM -0800, Paul Ramsey wrote:
>>>>> Just a reminder, if you build postgis with —enable-debug, the
>>>> PARANOIA_LEVEL gets bumped up, and that can have huge performance effects
>>>> which make any kind of benchmarking a whack-a-mole process.
>>>>> 
>>>>> I guess I internalized the idea that —enable-debug would just drop a ‘-g’ flag
>>>> into the build and that’s about it, but in fact it has these other deleterious effects.
>>>> Among other things, it makes lwcollection_add_lwgeom a couple orders of
>>>> magnitude slower.
>>>>> 
>>>>> Anyways, super important for anyone building for release too. You aren’t just
>>>> getting debug symbols!
>>>>> 
>>>>> I wonder if we should split off —enable-debug from other “developer
>>>> affordances”, in a different option, kind of like how pgsql as —enable-cassert and
>>>> some other #define only options for things like memory checking and so on.
>>>> 
>>>> +1 --enable-paranoia would sound good
>>> 
>>> +1
>> 
>> Actually I guess it should be --with-paranoia-level N
>> 
>> --strk;
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20240118/260aee34/attachment-0001.htm>


More information about the postgis-devel mailing list