On 2013-11-05 17:19:21 -0500, Tom Lane wrote: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers