On 2013-11-05 17:19:21 -0500, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On that note, any chance you remember why you increased MAX_LOCKMODE by
> > 2 to 10 back in 2001 although AccessExclusiveLock is 8? The relevant
> > commit is 4fe42dfbc3bafa0ea615239d716a6b37d67da253 .
>
> Probably because it seemed like a round number, which 9 wasn't ...
> keep in mind that this data structure is nominally intended to support
> other lock semantics besides what LockConflicts[] defines.
Hm. Given that there are Assert()s for MAX_LOCKMODE around, that adding
a new method isn't possible without editing lock.c and that we use it to
in shared memory structures I am not sure I see the point of that slop.
Anyway, it was just a point of curiosity.
> (BTW,
> it's a conceptual error to imagine that the numerical values of the
> lock mode codes define a strict "strength" ordering, which is another
> reason I don't care for your patch.)
Well, while I don't thing it has too much practical bearing, we could
just check for *any* lock already held instead, that's all we need for
the added checks. I thought it might be more useful to get the strongest
lock rather than any lock for other potential checks, but if that's a
contentious point...
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
