Re: Assert Levels - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Assert Levels
Date
Msg-id 1221891921.4445.70.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Assert Levels  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Assert Levels  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 2008-09-19 at 17:47 -0400, Tom Lane wrote:
> Greg Smith <gsmith@gregsmith.com> writes:
> > On Fri, 19 Sep 2008, Greg Stark wrote:
> >> 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.
> 
> > The performance impact of assertions is large enough that I don't think 
> > that goal is practical.
> 
> Well, there are certain things that --enable-cassert turns on that are
> outrageously expensive; notably CLOBBER_FREED_MEMORY and
> MEMORY_CONTEXT_CHECKING.  It wouldn't be too unreasonable to decouple
> those things somehow (with a means more accessible than editing
> pg_config_manual.h).

That's mostly what I'm hoping for. If we call the CLOBBER checks as
class 3, all current Asserts as class 2 then we can invent a class 1 of
specifically lightweight checks (only). We can then have
--enable-cassert=X rather than just y or n

> I don't think anyone knows what the performance impact of just the
> regular Asserts is; it's been too long since these other things were
> stuck in there.

Agreed. If we had a system in place, we would slowly move towards using
it. It wouldn't happen overnight, but it would help. Many more people
might be persuaded to be early adopters if there was an extra mode in
place to catch problems. 

My thinking was that I want to put lots of checks into Hot Standby to
prove it all works, but in places where I don't think they're really
needed.

An example of a current set of checks we do, that may not be needed are
the tests for HeapTupleInvisible in HeapTupleSatisfiesUpdate(). Almost
every time we do a TransactionIdIsInProgress() to see if the heap tuple
is invisible. If it is we throw an ERROR. But we already did that
earlier. Now I've never seen that ERROR reported anywhere, so I'm
thinking that I'd like to downgrade that somehow, yet still retain the
ability to check it when things go strange. There are a few other
examples.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Assert Levels
Next
From: "Darren Weber"
Date:
Subject: macport for libpqxx