On Sat, 2008-09-20 at 11:28 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Fri, 2008-09-19 at 17:47 -0400, Tom Lane wrote:
> >> Well, there are certain things that --enable-cassert turns on that are
> >> outrageously expensive; notably CLOBBER_FREED_MEMORY and
> >> MEMORY_CONTEXT_CHECKING. It wouldn't be too unreasonable to decouple
> >> those things somehow (with a means more accessible than editing
> >> pg_config_manual.h).
>
> > That's mostly what I'm hoping for. If we call the CLOBBER checks as
> > class 3, all current Asserts as class 2 then we can invent a class 1 of
> > specifically lightweight checks (only). We can then have
> > --enable-cassert=X rather than just y or n
>
> Hold on a minute. I don't mind refactoring the way that configure
> controls those existing build switches. I do object to complexifying
> routine uses of Assert when absolutely zero evidence of a benefit has
> been presented. How do you know that the run-of-the-mill Asserts aren't
> lightweight enough already?
Well, we don't. That's why I'd suggest to do it slowly and classify
everything as medium weight until proven otherwise. Also think we need
to take code location into account, because a cheap test in a critical
place could end up costing more than an expensive test that hardly ever
gets executed.
Anyway, if we do it at all, I think this probably should be classified
as code cleanup and done later in release cycle. If you think it's a
good idea after a couple of months we can start on it.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
