From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Cost of AtEOXact_Buffers in --enable-cassert |
Date: | 2010-08-16 11:57:39 |
Message-ID: | AANLkTikfX+Eg90O6Pq47Zcz9rjqXMjyy4XJzooyjeZMS@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 16, 2010 at 4:00 AM, Greg Smith <greg(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2010-08-16 12:22:47 | Re: patch for pg_ctl.c to add windows service start-type |
Previous Message | Quan Zongliang | 2010-08-16 11:49:20 | patch for pg_ctl.c to add windows service start-type |