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]