Obscure: correctness of lock manager???

Hi,

I'm doing research on locking pattern of applications. I chose PostgreSQL
7.3.3 as an example application due to availability of sourcecode.

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. I ran the DBT3 benchmark from OSDL on top of PostgreSQL, which
should be very similar to the well-known TCP-H benchmark. I ran with
small scalefactors (0.05, 0.1) and 8 or 16 backend processes.

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. To check that, I added additional traces
and found that the lock manager NEVER blocked, it ALWAYS ran through!

I don't understand the rationales behind the lock manager deeply, but
if my observations were true, it would mean that you just could
eliminate the lockmanager at all without producing a different behaviour.
To my understanding, the only side-effect of a lockmanager is just to
delay processes in case of conflicts. If never a delay occurs, the
lock manager has no effect.

Probably a database without any lock manager does not satisfy correctness,
such as ACID properties.

However, the source code is written very cleanly and carefully, and
it seems that the authors had some reasons for implementing it that
way as it looks like.

I found that LockCheckConflicts() did the first shortcut return almost
all times, leading to that presumably wrong behaviour. However, I found
other cases where the code after the comment "Rats." was entered, also
sometimes leading to bad grants of conflicting locks. Interestingly,
I found no single case where LockCountMyLocks() was ever called.

I don't understand the lock manager deeply enough to trace down that
presumable bug.

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. When a process holds locks for different transactions,
the conflicts should be checked on _transaction_ level, not on process
level. Otherwise ACID could be violated, e.g. when SQL statements of
multiple txns are executed by one process in an interleaved way, there
would be NO locking at all. In my opinion, this could violate ACID.

Can anybody explain me the rationales behind the lock manager
implementation? Have I overlooked something? Did I miss something?

Cheers,

Thomas

[Sorry if similar postings appeared several times in the mailing list,
I had some problems with majordomo]