Greg Stark <gsstark@mit.edu> writes:
> Neil Conway <neilc@samurai.com> writes:
>> I think the percentage of deployments that enable assertions (which
>> causes a runtime performance hit) but NOT debugging info (which does
>> not) is pretty small.
> How big a penalty is it? If it's small, or if it could be made small by making
> a few assertions require an extra extra-assertions option, then perhaps it
> would make more sense to ship with it enabled?
We generally don't recommend enabling assertions in production
installations, because it's not clear that there is any net gain in
stability from doing so. Per the manual:
--enable-cassert
Enables assertion checks in the server, which test for many "can't happen" conditions. This is
invaluablefor code development purposes, but the tests slow things down a little. Also, having the tests
turnedon won't necessarily enhance the stability of your server! The assertion checks are not categorized
forseverity, and so what might be a relatively harmless bug will still lead to server restarts if it triggers
an assertion failure. Currently, this option is not recommended for production use, but you should have it
onfor development work or when running a beta version.
Obviously this does not apply to cases where the assert is testing
for something that will cause a core dump anyway, like an improperly
NULL pointer. But there are many, many asserts for things that are
probably not serious bugs (at worst they might deserve a FATAL exit,
rather than a system-wide PANIC).
Peter E. has speculated about improving the Assert facility to allow
categorization along this line, but I dunno when it will happen.
As far as your original question goes, I find that
MEMORY_CONTEXT_CHECKING and CLOBBER_FREED_MEMORY are quite expensive,
and presently --enable-cassert turns these on. But of course we could
decouple that if we were going to encourage people to run with asserts
enabled in production. I don't think asserts are hugely expensive
otherwise (though that might change if we sprinkle them as liberally
as Gaetano's proposal implies...)
regards, tom lane