Re: Cost of AtEOXact_Buffers in --enable-cassert - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Cost of AtEOXact_Buffers in --enable-cassert
Date
Msg-id 4C68F022.50903@2ndquadrant.com
Whole thread Raw
In response to Re: Cost of AtEOXact_Buffers in --enable-cassert  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Cost of AtEOXact_Buffers in --enable-cassert
List pgsql-hackers
Tom Lane wrote:
> Nobody else seems to have commented, but maybe what this suggests is
> we need to be able to individually disable a few of the most expensive
> checks.  I'm not sure what a reasonable API is for that ... not sure
> that I like the thought of a GUC for each one.
>   

I'd really like to be able to do more long-running performance tests 
with the rest of the assertions on, to help catch bugs in higher level 
code.  There's maybe three major categories of these people might want 
to turn off, right?  If you consider wal_debug as an example of 
something similar that's already there, the footprint of supporting that is:

-15 lines in config.sgml
-12 lines in guc.c
-4 lines in xlog.c

Plus all the places that have the #IFDEF around them to only enable if 
this is on, which is the same regardless of the UI to toggle it.  So 
there'd be ~35 lines of new code per option to add them in the same way, 
as GUCs you can view but not set, and that aren't included in the 
postgresql.conf.sample and such.

Right now --enable-cassert => debug_assertions makes it easy on the user 
side to figure out whether they have the expensive debugging stuff 
turned on from a UI everybody knows--type a psql command.  I'm biased 
toward just doing the minor cut/paste bloat to do something similar for 
the most expensive performance bits too.  Then, as this escapes into the 
wild, we can continue to sort out performance reports that easily.  As 
I've ran into a few times now, not everybody even has pg_config 
installed, because it's usually sitting in a devel package instead of 
the main server one.

If it's compiler option only, no GUC, and you have to use pg_config to 
figure out if you did it, that's completely acceptable too.  I don't 
have a strong opinion here, just a preference.  No arguments from me if 
the decision is "that's too much code to add for something so marginal".

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us



pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Recognize functional dependency on primary keys.
Next
From: Dean Rasheed
Date:
Subject: Re: Proposal / proof of concept: Triggers on VIEWs