Re: Assert Levels

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?

> An example of a current set of checks we do, that may not be needed are
> the tests for HeapTupleInvisible in HeapTupleSatisfiesUpdate().

Yes, they are needed, think about concurrent updates: sure the tuple
must have been visible awhile back, but we haven't been holding
exclusive lock on its buffer continuously since then.  There might be
some places where test-and-elog checks could be downgraded to
assertions, but I would tread very very carefully in that.  If the
original code author was sure it "couldn't happen" he'd have written it
as an Assert to begin with.
        regards, tom lane