Greg Stark <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> 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 invaluable for code
development purposes, but the tests slow things down a
little. Also, having the tests turned on won't necessarily
enhance the stability of your server! The assertion checks are
not categorized for severity, 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 on for
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
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
