数据库系统

开发平台：
Unix_Linux

lock.l：源码内容
							." This is -*-nroff-*-
." XXX standard disclaimer belongs here....
." $Header: /usr/local/cvsroot/pgsql/src/man/Attic/lock.l,v 1.9 1999/06/09 03:51:40 vadim Exp $
.TH LOCK SQL 01/23/93 PostgreSQL PostgreSQL
.SH NAME
lock - Explicit lock of a table inside a transaction
.SH SYNOPSIS
.nf
fBlockfR [fBtablefR] classname
fBlockfR [fBtablefR] classname fBinfR [fBrowfR|fBaccessfR] {fBsharefR|fBexclusivefR} fBmodefR
fBlockfR [fBtablefR] classname fBinfR fBshare row exclusivefR fBmodefR
.fi
.SH DESCRIPTION
Available lock modes from least restrictive to most restrictive:
.PP
fBACCESS SHARE MODEfR
fBNotefR: this lock mode is acquired automatically over tables being
queried. fBPostgresfR releases automatically acquired
ACCESS SHARE locks after statement is done.
This is the least restrictive lock mode which conflicts with ACCESS EXCLUSIVE
mode only. It's intended to protect table being queried from concurrent
fBALTER TABLEfR, fBDROP TABLEfR and
fBVACUUMfR statements over the same table.
fBROW SHARE MODEfR
fBNotefR: Automatically acquired by SELECT FOR UPDATE statement.
Conflicts with EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
fBROW EXCLUSIVE MODEfR
fBNotefR: Automatically acquired by UPDATE, DELETE, INSERT statements.
Conflicts with SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE and ACCESS EXCLUSIVE
modes. Generally means that a transaction updated/inserted some tuples in a
table.
fBSHARE MODEfR
fBNotefR: Automatically acquired by CREATE INDEX statement.
Conflicts with ROW EXCLUSIVE, SHARE ROW EXCLUSIVE, EXCLUSIVE and ACCESS
EXCLUSIVE modes. This mode protects a table against concurrent updates.
fBSHARE ROW EXCLUSIVE MODEfR
Conflicts with ROW EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE, EXCLUSIVE and
ACCESS EXCLUSIVE modes. This mode is more restrictive than SHARE mode
because of only one transaction at time can hold this lock.
fBEXCLUSIVE MODEfR
Conflicts with ROW SHARE, ROW EXCLUSIVE, SHARE, SHARE ROW EXCLUSIVE,
EXCLUSIVE and ACCESS EXCLUSIVE modes. This mode is yet more restrictive than
SHARE ROW EXCLUSIVE one - it blocks concurrent SELECT FOR UPDATE queries.
fBACCESS EXCLUSIVE MODEfR
fBNotefR: Automatically acquired by ALTER TABLE, DROP TABLE, VACUUM
statements.
This is the most restrictive lock mode which conflicts with all other
lock modes and protects locked table from any concurrent operations.
fBNotefR: This lock mode is also acquired by first form of LOCK TABLE
(i.e. without explicit lock mode option).
.SH USAGE
.BR Postgres
always uses less restrictive lock modes ever possible. LOCK TABLE statement
provided for cases when you might need in more restrictive locking.
.PP
For example, application run transaction at READ COMMITTED isolation level
and need to ensure existance data in a table for duration of transaction. To
achieve this you could use SHARE lock mode over table before querying. This
will protect data from concurrent changes and provide your further read
operations over table with data in their real current state, because of
SHARE lock mode conflicts with ROW EXCLUSIVE one, acquired by writers, and
your LOCK TABLE table IN SHARE MODE statement will wait untill concurrent
write operations (if any) commit/rollback. (Note that to read data in their
real current state running transaction at SERIALIZABLE isolation level you
have to execute LOCK TABLE statement before execution any DML statement,
when transaction defines what concurrent changes will be visible to
herself).
If, in addition to requirements above, transaction is going to change data
in a table then SHARE ROW EXCLUSIVE lock mode should be acquired to prevent
deadlock conditions when two concurrent transactions would lock table in
SHARE mode and than would try to change data in this table, both
(implicitly) acquiring ROW EXCLUSIVE lock mode that conflicts with
concurrent SHARE lock.
  
Following deadlock issue (when two transaction wait one another)
touched above, you should follow two general rules to prevent 
deadlock conditions:
  
fB1. Transactions have to acquire locks on the same objects in the same order.fR
   
For example, if one application updates row R1 and than updates row R2 (in
the same transaction) then second application shouldn't update row R2 if
it's going update row R1 later (in single transaction).  Instead, it should
update R1 and R2 rows in the same order as first application.
fB2. Transactions should acquire two conflicting lock modes only if one of
them is self-conflicting (i.e. may be held by one transaction at time only)
and should acquire most restrictive mode first.fR
   
Example for this rule is described above when told about using
SHARE ROW EXCLUSIVE mode instead of SHARE one.
fBNotefR: fBPostgresfR does detect deadlocks and will rollback one of
waiting transactions to resolve the deadlock.
.SH COMPATIBILITY
LOCK TABLE statement is a fBPostgresfR language extension.
Except for ACCESS SHARE/EXCLUSIVE lock modes, all other fBPostgresfR lock
modes and LOCK TABLE statement syntax are compatible with fBOraclefR
ones.
.SH EXAMPLES
.nf
--
-- SHARE lock primary key table when going to perform
-- insert into foreign key table.
--
BEGIN WORK;
LOCK TABLE films IN SHARE MODE;
SELECT id FROM films 
  WHERE name = 'Star Wars: Episode I - The Phantom Menace';
--
-- Do ROLLBACK if record was not returned
--
INSERT INTO films_user_comments VALUES 
  (_id_, 'GREAT! I was waiting it so long!');
COMMIT WORK;
--
-- SHARE ROW EXCLUSIVE lock primary key table when going to perform
-- delete operation.
--
BEGIN WORK;
LOCK TABLE films IN SHARE ROW EXCLUSIVE MODE;
DELETE FROM films_user_comments WHERE id IN
  (SELECT id FROM films WHERE rating < 5);
DELETE FROM films WHERE rating < 5;
COMMIT WORK;
.SH "SEE ALSO"
begin(l),
commit(l),
set(l),
select(l).

						