2010/4/7 Greg Smith <g...@2ndquadrant.com>: > Merlin Moncure wrote: > > On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > > Greg has the right idea: show debug_assertions. > > > why not the entire set of configure options? > > > Given that the standard way to find those is pg_config, there's a couple of > reasons why not to prefer that, on top of those Tom already mentioned: > > 1) pg_config isn't in the standard PostgreSQL package set in some > distributions (it's sometimes in the -devel package), so it may not be > available; debug_assertions is always there if you have psql. For my goals, > which include benchmarking scripts I often distribute to other people, that > matters. > > 2) It's easy to get pg_config output from your client that doesn't actually > match the running server, particularly when developing. That's been the > source of more than one of the times I was running a debug build on the > server but didn't notice it, and therefore would have produced worthless > performance numbers. Given that the main slowdowns from having assertions > turned on are server side, whether or not the local client running things > like psql have them turned on or not doesn't worry me as much. > > 3) It's a little easier to check the value of "show" in a script to confirm > you're not running a bad build than to parse the output from pg_config. > Here's the recipe I use for shell scripts: > > #!/bin/sh > DEBUG=`psql -At -c "show debug_assertions"` > if [ "$DEBUG" = "on" ] ; then > echo "Debug build - aborting performance test" > exit 1 > fi > > Pushing this data into something like version() would solve the first two > items above, while making the issue of how to parse the results in a test > client even harder, given there's already too much junk in one big string > there. You couldn't make the above check much simpler, which makes it hard > to justify any alternative approach to grab this data. >
good idea. Can do it to 9.0? It has zero impact on behave and can help to protect us against same bug. I plan one night test fest on begin of may in Prague, and wouldn't do same mistake :). But it is really import feature - maybe can signaled in promt in future. Regards Pavel Stehule > -- > Greg Smith 2ndQuadrant US Baltimore, MD > PostgreSQL Training, Services and Support > g...@2ndquadrant.com www.2ndQuadrant.us > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers