From: Tom Lane on
Merlin Moncure <mmoncure(a)gmail.com> writes:
> On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>> Greg has the right idea: show debug_assertions.

> why not the entire set of configure options?

We've discussed that before. pg_config already provides that info,
and there was some concern about security risks of exposing it inside
the database. (In particular, we currently go to some lengths to not
expose any file path information to non-superusers.) If there's a
reason to expose *individual* configuration options that aren't already
easily checkable, we could discuss that.

I would be against sticking it into version() output in any case.
That function's already overloaded beyond any sane interpretation
of its purpose, to the point where it's difficult to make use of
the output programmatically.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Greg Smith on
Merlin Moncure wrote:
> On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane <tgl(a)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.

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

From: Pavel Stehule on
2010/4/7 Greg Smith <greg(a)2ndquadrant.com>:
> Merlin Moncure wrote:
>
> On Tue, Apr 6, 2010 at 3:58 PM, Tom Lane <tgl(a)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
> greg(a)2ndQuadrant.com www.2ndQuadrant.us
>

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers