Simplify shared-memory lock data structures as per recent discussion:
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 14 Jun 2005 22:15:33 +0000 (22:15 +0000)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 14 Jun 2005 22:15:33 +0000 (22:15 +0000)
commit8563ccae2caf0119355c5c80cfa59da19ce809d6
treec53bd9d44280939a986d44e26d7ee1f29216cb3e
parentf5835b4b8d569e4d7814886f9e7b90c36d8a4fb5
Simplify shared-memory lock data structures as per recent discussion:
it is sufficient to track whether a backend holds a lock or not, and
store information about transaction vs. session locks only in the
inside-the-backend LocalLockTable.  Since there can now be but one
PROCLOCK per lock per backend, LockCountMyLocks() is no longer needed,
thus eliminating some O(N^2) behavior when a backend holds many locks.
Also simplify the LockAcquire/LockRelease API by passing just a
'sessionLock' boolean instead of a transaction ID.  The previous API
was designed with the idea that per-transaction lock holding would be
important for subtransactions, but now that we have subtransactions we
know that this is unwanted.  While at it, add an 'isTempObject' parameter
to LockAcquire to indicate whether the lock is being taken on a temp
table.  This is not used just yet, but will be needed shortly for
two-phase commit.
contrib/userlock/user_locks.c
src/backend/commands/vacuum.c
src/backend/storage/lmgr/README
src/backend/storage/lmgr/lmgr.c
src/backend/storage/lmgr/lock.c
src/backend/storage/lmgr/proc.c
src/include/storage/lmgr.h
src/include/storage/lock.h