Obscure: correctness of lock manager??? - Mailing list pgsql-hackers
From | Thomas Schoebel-Theuer |
---|---|
Subject | Obscure: correctness of lock manager??? |
Date | |
Msg-id | 200308282053.h7SKrdX9024511@eiche.informatik.uni-stuttgart.de Whole thread Raw |
Responses |
Re: Obscure: correctness of lock manager???
|
List | pgsql-hackers |
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]
pgsql-hackers by date: