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

Jim C. Nasby wrote:
> On Mon, Oct 31, 2005 at 01:01:14PM -0500, Bruce Momjian wrote:
> > > This incident has made me wonder if it's worth creating two classes of
> > > assertions. The (hopefully more common) set of assertions would be for
> > > things that shouldn't happen, but if go un-caught won't result in heap
> > > corruption. A new set (well, existing asserts, but just re-classified)
> > > would be for things that if uncaught could result in heap corruption. My
> > > hope is that the set of critical assertions could be turned on by
> > > default, helping to identify race conditions and other bugs that
> > > conventional testing is unlikely to find.
> >
> > That is probably overkill. Running with test patches isn't something we
> > expect folks to do often.
>
> I wasn't thinking about test patches.
>
> 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.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073