Re: dynamic shared memory and locks - Mailing list pgsql-hackers

From Andres Freund
Subject Re: dynamic shared memory and locks
Date
Msg-id 20140107115437.GB14280@awork2.anarazel.de
Whole thread Raw
In response to Re: dynamic shared memory and locks  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: dynamic shared memory and locks
List pgsql-hackers
On 2014-01-06 21:35:22 -0300, Alvaro Herrera wrote:
> 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 don't think it's that unlikely as the previous implementation's rules
when viewed while squinting allowed nesting spinlocks. And it's a pretty
simple check.

> 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.

I don't think that check would have relevantly high performance impact
in comparison to the rest of --enable-cassert - it's a single process
local variable which is regularly accessed. It will just stay in
L1 or even registers.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: generic pseudotype IO functions?
Next
From: Florian Pflug
Date:
Subject: Re: ERROR: missing chunk number 0 for toast value