On 2014-05-22 16:37:35 -0400, Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
