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

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:

> Jim C. Nasby wrote:
>
> > My assumption is that the asserts that are currently in place fall into
> > one of two categories: either they check for something that if false
> > could result in data corruption in the heap, or they check for something
> > that shouldn't happen, but if it does it can't corrupt the heap. If that
> > assumption is correct then seperating them might make it easier to run
> > with the set of critical asserts turned on. Currently, there can be a
> > substantial performance penalty with all asserts turned on, but I
> > suspect a lot of that penalty is from asserts in things like parsing and
> > planning code; code that pretty much couldn't corrupt data.
>
> There is no way if the system has some incorrect value whether that
> would later corrupt the data or not. Anything the system does that it
> shouldn't do is a potential corruption problem.

That's true but the reason why is subtler than that. If something has happened
that "can't happen" then there's no way to know how you arrived in that
situation. You might already have major problems that can lead to data
corruption -- or for that matter have already caused data corruption..

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.

--
greg