Greg Stark <gsstark@mit.edu> writes:
> I happen to think that except for the rare assertion that has major
> performance impact all the assertions should be on in production builds. The
> goal of assertions is to catch corruption quickly and that's something that's
> just as important in production as it is in debugging.
You seem not to have read the documentation:
<term><option>--enable-cassert</option></term>
Enables <firstterm>assertion</> checks in the server, which test for many <quote>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
arenot categorized for severity, and so what might be a relatively harmless bug will still lead to server
restartsif 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.
The great thing about Assert() is that you can throw one in for any
condition that your code is assuming-without-proof, without having to
think too hard about consequences. If we were to recommend having
enable-cassert on in production databases, we would need a MUCH higher
standard of care about when to use Assert. I would bet that ninety
percent of the Asserts in the existing code are on conditions that could
represent, at worst, corruption of backend-local or even
transaction-local data structures. Taking down the entire database
cluster for that is not something that sounds like a stability-enhancing
tradeoff to me.
In other words, the "you don't know how bad it might be" theory has a
flip side: you can't cry wolf when there's no wolf, either, at least not
if you want to continue to be listened to.
regards, tom lane
