Re: dynamic shared memory and locks

Jim Nasby escribió:
> On 1/6/14, 2:59 PM, Robert Haas wrote:
> >On Mon, Jan 6, 2014 at 3:57 PM, Tom Lane <tgl@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
capabilitiesso 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
criticalpath).
 
> 
> If we had a more aggressive form of assert (assert_anal? :)) we could use that here and let the buildfarm bore the
bruntof 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