postgresql/src/backend/storage/lmgr
Bruce Momjian 7ea8403c8a The beos port in the source tree doesn't even compile. and even
after that dynamic loading isn't working and shared memory handling is
broken.

        Attached with this message, there is a Zip file which contain :

        * beos.diff = patch file generated with difforig
        * beos = folder with beos support files which need to be moved in /
src/backend/port
        * expected = foler with three file for message and precision
difference in regression test
        * regression.diff = rule problem (need to kill the backend manualy)
        * dynloader = dynloader files (they are also in the pacth files,
but there is so much modification that I have join full files)

        Everything works except a problem in 'rules' Is there some problems
with rules in the current tree ? It used to works with last week tree.

Cyril VELTER
2000-10-07 14:39:21 +00:00
..
lmgr.c Mark functions as static and ifdef NOT_USED as appropriate. 2000-06-08 22:38:00 +00:00
lock.c Revise aggregate functions per earlier discussions in pghackers. 2000-07-17 03:05:41 +00:00
Makefile Fix relative path references so that make knowns which dependencies refer 2000-08-31 16:12:35 +00:00
multi.c Add: 2000-01-26 05:58:53 +00:00
proc.c The beos port in the source tree doesn't even compile. and even 2000-10-07 14:39:21 +00:00
README Update lock manager README. 1998-07-06 18:16:07 +00:00
single.c Add: 2000-01-26 05:58:53 +00:00

$Header: /cvsroot/pgsql/src/backend/storage/lmgr/README,v 1.3 1998/07/06 18:16:07 momjian Exp $

There are two fundemental lock structures.  Lock methods describe the
locking behavior.  We currently only support multi-level locking.  Lock
modes describe the mode of the lock(read/write or shared/exclusive). 
See src/tools/backend/index.html and src/include/storage/lock.h for more
details.

---------------------------------------------------------------------------

The lock manager's LOCK:

tag -
    The key fields that are used for hashing locks in the shared memory
    lock hash table.  This is kept as a separate struct to ensure that we
    always zero out the correct number of bytes.  This is a problem as
    part of the tag is an itempointer which is 6 bytes and causes 2
    additional bytes to be added as padding.

    tag.relId -
	Uniquely identifies the relation that the lock corresponds to.
    
    tag.dbId -
	Uniquely identifies the database in which the relation lives.  If
	this is a shared system relation (e.g. pg_user) the dbId should be
	set to 0.

    tag.tupleId -
	Uniquely identifies the block/page within the relation and the
	tuple within the block.  If we are setting a table level lock
	both the blockId and tupleId (in an item pointer this is called
	the position) are set to invalid, if it is a page level lock the
	blockId is valid, while the tuleId is still invalid.  Finally if
	this is a tuple level lock (we currently never do this) then both
	the blockId and tupleId are set to valid specifications.  This is
	how we get the appearance of a multi-level lock table while using
	only a single table (see Gray's paper on 2 phase locking if
	you are puzzled about how multi-level lock tables work).

mask -
    This field indicates what types of locks are currently held in the
    given lock.  It is used (against the lock table's conflict table)
    to determine if the new lock request will conflict with existing
    lock types held.  Conficts are determined by bitwise AND operations
    between the mask and the conflict table entry for the given lock type
    to be set.  The current representation is that each bit (1 through 5)
    is set when that lock type (WRITE, READ, WRITE INTENT, READ INTENT, EXTEND)
    has been acquired for the lock.

waitProcs -
    This is a shared memory queue of all process structures corresponding to
    a backend that is waiting (sleeping) until another backend releases this
    lock.  The process structure holds the information needed to determine
    if it should be woken up when this lock is released.  If, for example,
    we are releasing a read lock and the process is sleeping trying to acquire
    a read lock then there is no point in waking it since the lock being
    released isn't what caused it to sleep in the first place.  There will
    be more on this below (when I get to releasing locks and waking sleeping
    process routines).

nHolding -
    Keeps a count of how many times this lock has been attempted to be
    acquired.  The count includes attempts by processes which were put
    to sleep due to conflicts.  It also counts the same backend twice
    if, for example, a backend process first acquires a read and then
    acquires a write.

holders -
    Keeps a count of how many locks of each type have been attempted.  Only
    elements 1 through MAX_LOCK_TYPES are used as they correspond to the lock
    type defined constants (WRITE through EXTEND).  Summing the values of
    holders should come out equal to nHolding.

nActive -
    Keeps a count of how many times this lock has been succesfully acquired.
    This count does not include attempts that were rejected due to conflicts,
    but can count the same backend twice (e.g. a read then a write -- since
    its the same transaction this won't cause a conflict)

activeHolders -
    Keeps a count of how locks of each type are currently held.  Once again
    only elements 1 through MAX_LOCK_TYPES are used (0 is not).  Also, like
    holders, summing the values of activeHolders should total to the value
    of nActive.

---------------------------------------------------------------------------