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

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> 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:

Sure I have, I just disagree.

> 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.

It may be minor corruption or it may be that the reason for the minor
corruption comes from some larger bug. It may also be backend-local or
transaction-local corruption at the time the assert catches it but cause major
damage by the time it actually crashes a non-assert-enabled database.

--
greg