On Mon, Aug 16, 2010 at 4:00 AM, Greg Smith <g...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
