database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-09 17:03:00 +03:00
Code Activity

Update to /contrib from Karel.

Browse Source
This commit is contained in:
Bruce Momjian
2000-06-19 13:54:50 +00:00
parent b2c56574e1
commit 6de7d4fe91
87 changed files with 257 additions and 1645 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
contrib/userlock/Makefile
View File

@@ -1,5 +1,5 @@
#
# $Header: /cvsroot/pgsql/contrib/userlock/Attic/Makefile,v 1.9 2000/06/16 18:59:28 momjian Exp $
# $Header: /cvsroot/pgsql/contrib/userlock/Attic/Makefile,v 1.10 2000/06/19 13:54:44 momjian Exp $
#
TOPDIR=../..
@@ -10,7 +10,7 @@ NAME = user_locks
PROGRAM =
OBJS = $(NAME).o
DOCS = README
DOCS = README.$(NAME)
SQLS = $(NAME).sql
BINS =
EXAMPLES=
@@ -29,7 +29,7 @@ install: install_doc install_sql install_mod
install_doc:
for inst_file in $(DOCS); do \
$(INSTALL) $(INSTL_LIB_OPTS) $$inst_file $(CONTRIB_DOCDIR)/$(DOCS).$(NAME); \
$(INSTALL) $(INSTL_LIB_OPTS) $$inst_file $(CONTRIB_DOCDIR); \
done
install_sql:

55
contrib/userlock/README
View File

@@ -1,55 +0,0 @@
User locks, by Massimo Dal Zotto <dz@cs.unitn.it>
Copyright (C) 1999, Massimo Dal Zotto <dz@cs.unitn.it>
This software is distributed under the GNU General Public License
either version 2, or (at your option) any later version.
This loadable module, together with my user-lock.patch applied to the
backend, provides support for user-level long-term cooperative locks.
For example one can write:
select some_fields, user_write_lock_oid(oid) from table where id='key';
Now if the returned user_write_lock_oid field is 1 you have acquired an
user lock on the oid of the selected tuple and can now do some long operation
on it, like let the data being edited by the user.
If it is 0 it means that the lock has been already acquired by some other
process and you should not use that item until the other has finished.
Note that in this case the query returns 0 immediately without waiting on
the lock. This is good if the lock is held for long time.
After you have finished your work on that item you can do:
update table set some_fields where id='key';
select user_write_unlock_oid(oid) from table where id='key';
You can also ignore the failure and go ahead but this could produce conflicts
or inconsistent data in your application. User locks require a cooperative
behavior between users. User locks don't interfere with the normal locks
used by postgres for transaction processing.
This could also be done by setting a flag in the record itself but in
this case you have the overhead of the updates to the records and there
could be some locks not released if the backend or the application crashes
before resetting the lock flag.
It could also be done with a begin/end block but in this case the entire
table would be locked by postgres and it is not acceptable to do this for
a long period because other transactions would block completely.
The generic user locks use two values, group and id, to identify a lock,
which correspond to ip_posid and ip_blkid of an ItemPointerData.
Group is a 16 bit value while id is a 32 bit integer which could also be
an oid. The oid user lock functions, which take only an oid as argument,
use a group equal to 0.
The meaning of group and id is defined by the application. The user
lock code just takes two numbers and tells you if the corresponding
entity has been succesfully locked. What this mean is up to you.
My succestion is that you use the group to identify an area of your
application and the id to identify an object in this area.
Or you can just lock the oid of the tuples which are by definition unique.
Note also that a process can acquire more than one lock on the same entity
and it must release the lock the corresponding number of times. This can
be done calling the unlock funtion until it returns 0.