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

On Thu, Nov 03, 2005 at 11:11:42AM -0500, Tom Lane wrote:
> Perhaps rather than an all-or-nothing debug_assertions GUC variable,
> what we want is something that turns on or off "expensive" assertion
> checks at runtime. This could include MEMORY_CONTEXT_CHECKING and
> anything else where the actual checking of the condition is nontrivial.
> (For instance, there is code in list.c that grovels over the whole
> list for a consistency check --- that is "expensive". There is some
> code in the bufmgr that scans through all the buffers --- ditto.)

Two levels of assertions sounds like a great idea... wish I'd thought of
it! ;P

Seriously, I am wondering about the performance hit of always checking
debug_assertions.
http://archives.postgresql.org/pgsql-hackers/2005-08/msg00389.php
indicates that even with debug_assertions=false, --enable-cassert has a
big performance impact.

I don't really see any reason for debug_assertions unless we start
defaulting to assertions being compiled in. If we're going to split
things up maybe the expensive assertions you mention should get a
different macro so that there's no performance hit unless you
specifically compile them in. Michael's email tends to indicate that
going the other way around (one macro, two GUC's) wouldn't do any good.

BTW, I can do some testing of assert performance impact with dbt2 on a
Solaris box if anyone's interested in the data...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461