Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags

Greg Stark <gsstark(at)mit(dot)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 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.

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