On 2014-05-22 16:37:35 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.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.
I've used it once or twice to avoid having to recompile postgres when I
wanted things not to be *that* slow (AtEOXactBuffers() I am looking at
you). But I wouldn't be very sad if it'd go.
Anybody against that?
> 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.
Yes, that makes sense.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services