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 [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend