| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: -DDISABLE_ENABLE_ASSERT |
| Date: | 2014-05-22 20:37:35 |
| Message-ID: | 4650.1400791055@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> Since there seem to be multiple static checkers (coverity, clang
> checker) having problems with assert_enabled can we just optionally
> disable it?
> I am thinking of replacing it by a AssertionsEnabled() macro which then
> is unconditionally defined when DISABLE_ENABLE_ASSERT is defined.
We could do that ... but I wonder if we shouldn't remove assert_enabled
altogether. What's the use case for turning it off? Not matching the
speed of a non-cassert build, because for instance MEMORY_CONTEXT_CHECKING
doesn't get turned off.
If we went this direction I'd suggest keeping the GUC but turning it into
a read-only report of whether the backend was compiled with assertions.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-05-22 20:37:42 | Re: -DDISABLE_ENABLE_ASSERT |
| Previous Message | Andres Freund | 2014-05-22 20:31:24 | -DDISABLE_ENABLE_ASSERT |