mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-10-05 13:36:52 +02:00
31 lines
1.5 KiB
Plaintext
31 lines
1.5 KiB
Plaintext
|
User locks, by Massimo Dal Zotto <dz@cs.unitn.it>
|
||
|
|
||
|
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 (this example is written in TclX):
|
||
|
|
||
|
set rec [sql "select ...,user_write_lock_oid(oid) from table where id=$id"]
|
||
|
if {[keylget rec user_write_lock_oid] == 1} {
|
||
|
# the write lock has been acquired with the record, start
|
||
|
# a long editing session, then update the database and
|
||
|
# release the lock.
|
||
|
sql "update table set ... where id=$id"
|
||
|
sql "select user_write_unlock_oid([keylget rec oid])"
|
||
|
} else {
|
||
|
# the record has been read but the write lock couldn't be acquired,
|
||
|
# so it should not be modified by the application.
|
||
|
messageBox "This record is in use by another user, retry later"
|
||
|
}
|
||
|
|
||
|
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 record and there
|
||
|
may be some locks not released if the backend or the application crashes
|
||
|
before resetting the 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.
|
||
|
Note that this type of locks are handled cooperatively by the application
|
||
|
and do not interfere with the normal locks used by postgres. So an user
|
||
|
could still modify an user-locked record if he wanted to ignore the lock.
|