Re: Assert Levels - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Assert Levels
Date
Msg-id 91D0BC0B-0B0D-442E-9279-8B86D7EFFF53@enterprisedb.com
Whole thread Raw
In response to Re: Assert Levels  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Assert Levels  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers

greg

On 19 Sep 2008, at 20:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Greg Stark <greg.stark@enterprisedb.com> writes:
>> You'll also have to do enough empirical tests to convince people that
>> a --enable-cheap-casserts build really does perform the same as a
>> regular build.
>
> I don't think performance is even the main issue.  We have never
> recommended having Asserts on in production because they can decrease
> system-wide reliability.  As per the fine manual:

I think Simon's coming at this from a different angle - at least this  
is what I took out of his suggestion: there Might be bugs or "can't  
happen" events that can happen but only under heavy load. Currently  
anyone running heavy workloads does it with assertions off so we  
aren't testing that case.

There was a case of this that the HOT thesting turned up. There was a  
"can't happen" assertion failure related to hint bits being lost that  
was happening.

This is a good example of why running with assertions enabled on  
production might not be a good idea. But it's also a good example of  
why we should do our performance testing with assertions enabled if we  
can do it without invalidating the results. 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Assert Levels
Next
From: "A.M."
Date:
Subject: Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)