Robert Haas <[email protected]> writes:
> On Fri, Jun 4, 2010 at 11:45 AM, Tom Lane <[email protected]> wrote:
>> The reason for not recommending cassert in production builds is not
>> cost but stability.
> We routinely castigate people for benchmarking done with cassert
> turned on, and tell them their numbers are meaningless.
I didn't say it wasn't expensive ;-). But Kevin's question seemed to
be based on the assumption that runtime cost was the only negative.
It wouldn't be terribly hard to make a variant of cassert that skips
two or three of the most expensive things (particularly memory context
checking and CLOBBER_FREED_MEMORY), and from a cost perspective that
would be totally reasonable to run in production. We haven't done it
because of the stability issue.
regards, tom lane
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
