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.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461