Simon Riggs <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
