On Mon, Aug 16, 2010 at 4:00 AM, Greg Smith <greg@2ndquadrant.com> wrote:
> 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".
What if we just added one GUC whose remit was to disable some of the
things that enable-cassert does, with a comma-separated list of values
specifying which ones? We could turn it into a bit-field under the
covers.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company