Jim Nasby escribió: > On 1/6/14, 2:59 PM, Robert Haas wrote: > >On Mon, Jan 6, 2014 at 3:57 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> >>The point I'm making is that no such code should get past review, > >>whether it's got an obvious performance problem or not. > > > >Sure, I agree, but we all make mistakes. It's just a judgement call > >as to how likely you think it is that someone might make this > >particular mistake, a topic upon which opinions may vary. I agree that excessive optimism might cause problems in the future. Maybe it makes sense to have such a check #ifdef'ed out on most builds to avoid extra overhead, but not having any check at all just because we trust the review process too much doesn't strike me as the best of ideas. > There's been discussions in the past about the overhead added by testing and > having more than one level of test capabilities so that facilities like the > buildfarm can run more expensive testing without burdening developers with > that. ISTM this is another case of that (presumably Tom's concern is the > performance hit of adding an assert in a critical path). > > If we had a more aggressive form of assert (assert_anal? :)) we could use > that here and let the buildfarm bore the brunt of that cost. Sounds good, but let's not enable it blindly on all machines. There are some that are under very high pressure to build and test all the branches, so if we add something too costly on them it might cause trouble. So whatever we do, it should at least have the option to opt-out, or perhaps even make it opt-in. (I'd think opt-out is better, because otherwise very few machines are going to have it enabled at all.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
