Re: -DDISABLE_ENABLE_ASSERT

On 2014-05-22 16:37:35 -0400, Tom Lane wrote:
> 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.

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