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 <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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
