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

On Wed, Nov 02, 2005 at 02:04:09PM -0500, Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.com> writes:
> > BTW, that's a reversal from what I was originally arguing for, which was
> > due to the performance penalty associated with --enable-cassert. My
> > client is now running with Tom's suggestion of commenting out
> > CLOBBER_FREED_MEMORY and MEMORY_CONTEXT_CHECKING and performance is
> > good. It appears to be as good as it was with asserts disabled.
> 
> Interesting.  I've always wondered whether the "debug_assertions" GUC
> variable is worth the electrons it's printed on.  If you are running
> with asserts active, that variable actually slows things down, by
> requiring an additional bool test for every Assert.  I suppose the
> motivation was to allow the same compiled executable to be used for both
> assert-enabled and assert-disabled runs, but how many people really need
> that capability?

Not sure how that relates to CLOBBER_FREED_MEMORY and
MEMORY_CONTEXT_CHECKING :P, but I agree that it doesn't make sense to
have a GUC, at least not if asserts default to being compiled out.

Hrm... does debug_assertions end up changing assert_enabled?

BTW, is MEMORY_CONTEXT_CHECKING that expensive? It seems like it
shouldn't be, but I'm only guessing at what exactly it does...
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461