database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-30 11:03:19 +03:00
Code Activity

Restructure LOCKTAG as per discussions of a couple months ago.

Browse Source 
Essentially, we shoehorn in a lockable-object-type field by taking
a byte away from the lockmethodid, which can surely fit in one byte
instead of two.  This allows less artificial definitions of all the
other fields of LOCKTAG; we can get rid of the special pg_xactlock
pseudo-relation, and also support locks on individual tuples and
general database objects (including shared objects).  None of those
possibilities are actually exploited just yet, however.

I removed pg_xactlock from pg_class, but did not force initdb for
that change.  At this point, relkind 's' (SPECIAL) is unused and
could be removed entirely.
This commit is contained in:
Tom Lane
2005-04-29 22:28:24 +00:00
parent 32d3b47e6f
commit 3a694bb0a1
14 changed files with 347 additions and 255 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
contrib/userlock/README.user_locks
View File

@ -35,11 +35,11 @@ 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 generic user locks use two values, group and id, to identify a lock.
Each of these are 32-bit integers.
The oid user lock functions, which take only an OID as argument, store the
OID as "id" with 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
@ -47,7 +47,9 @@ entity has been successfully locked. What this means is up to you.
My suggestion 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.
In all cases, user locks are local to individual databases within an
installation.
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