Thomas Schoebel-Theuer <schoebel@informatik.uni-stuttgart.de> writes:
> I instrumented the file backend/storage/lmgr/lock.c with printf() statements
> in order to find out the locking behaviour of typical applications using
> locking.
> When I later analyzed the logfiles produced that way, I found a very strange
> behaviour: exclusive locks were granted in parallel, even to different
> processes running in parallel.
If that were actually true, we'd have noticed it before now ;-).
Either you broke something while adding instrumentation, or you are
misinterpreting your data.
> I found no single case where LockCountMyLocks() was ever called.
I'm leaning to the "you broke something" theory. LockCountMyLocks()
is in the main path of LockAcquire, and could only be missed if the
early-out path is taken due to already holding a lock of the required
type.
> What I also cannot understand: why are locks always granted if they
> confict with other locks held by the _same_ process? In my opinion,
> this should be incorrect.
It is convenient for our purposes. Consider for example
BEGIN;LOCK TABLE foo;INSERT INTO foo ...
If we did things as you suggest, this would fail, because the write lock
needed by the INSERT would conflict with the prior exclusive LOCK.
Working around that would require re-implementing essentially the same
we-don't-conflict-with-our-own-locks semantics outside the lock manager.
> When a process holds locks for different transactions,
We never hold locks for different transactions, because a backend does
only one thing at a time.
regards, tom lane