Re: [PATCHES] mcxt.c - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: [PATCHES] mcxt.c |
Date | |
Msg-id | 3F5DD84B.3090005@dunslane.net Whole thread Raw |
In response to | Re: [PATCHES] mcxt.c (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
The particular assertion that was proposed doesn't strike me as terribly useful - It should be checked at the point of call rather than inside pstrdup, I should have thought. Of course, that would make for lots of code bloat ... cases like this are when gdb is your friend. cheers andrew Tom Lane wrote: >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 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 > > >
pgsql-hackers by date: