Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit a794fb0

Browse files
committed
Convert the lock manager to use the new dynahash.c support for partitioned
hash tables, instead of the previous kluge involving multiple hash tables. This partially undoes my patch of last December.
1 parent b25dc48 commit a794fb0

File tree

7 files changed

+307
-236
lines changed

7 files changed

+307
-236
lines changed

src/backend/storage/lmgr/README

Lines changed: 30 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
$PostgreSQL: pgsql/src/backend/storage/lmgr/README,v 1.19 2005/12/11 21:02:18 tgl Exp $
1+
$PostgreSQL: pgsql/src/backend/storage/lmgr/README,v 1.20 2006/07/23 23:08:46 tgl Exp $
22

33

44
LOCKING OVERVIEW
@@ -148,13 +148,21 @@ The lock manager's PROCLOCK objects contain:
148148
tag -
149149
The key fields that are used for hashing entries in the shared memory
150150
PROCLOCK hash table. This is declared as a separate struct to ensure that
151-
we always zero out the correct number of bytes.
151+
we always zero out the correct number of bytes. It is critical that any
152+
alignment-padding bytes the compiler might insert in the struct be zeroed
153+
out, else the hash computation will be random. (Currently, we are careful
154+
to define struct PROCLOCKTAG so that there are no padding bytes.)
152155

153-
tag.lock
154-
SHMEM offset of the LOCK object this PROCLOCK is for.
156+
tag.myLock
157+
Pointer to the shared LOCK object this PROCLOCK is for.
155158

156-
tag.proc
157-
SHMEM offset of PGPROC of backend process that owns this PROCLOCK.
159+
tag.myProc
160+
Pointer to the PGPROC of backend process that owns this PROCLOCK.
161+
162+
Note: it's OK to use pointers here because a PROCLOCK never outlives
163+
either its lock or its proc. The tag is therefore unique for as long
164+
as it needs to be, even though the same tag values might mean something
165+
else at other times.
158166

159167
holdMask -
160168
A bitmask for the lock modes successfully acquired by this PROCLOCK.
@@ -191,12 +199,18 @@ Most operations only need to lock the single partition they are working in.
191199
Here are the details:
192200

193201
* Each possible lock is assigned to one partition according to a hash of
194-
its LOCKTAG value (see LockTagToPartition()). The partition's LWLock is
195-
considered to protect all the LOCK objects of that partition as well as
196-
their subsidiary PROCLOCKs. The shared-memory hash tables for LOCKs and
197-
PROCLOCKs are divided into separate hash tables for each partition, and
198-
operations on each hash table are likewise protected by the partition
199-
lock.
202+
its LOCKTAG value. The partition's LWLock is considered to protect all the
203+
LOCK objects of that partition as well as their subsidiary PROCLOCKs.
204+
205+
* The shared-memory hash tables for LOCKs and PROCLOCKs are organized
206+
so that different partitions use different hash chains, and thus there
207+
is no conflict in working with objects in different partitions. This
208+
is supported directly by dynahash.c's "partitioned table" mechanism
209+
for the LOCK table: we need only ensure that the partition number is
210+
taken from the low-order bits of the dynahash hash value for the LOCKTAG.
211+
To make it work for PROCLOCKs, we have to ensure that a PROCLOCK's hash
212+
value has the same low-order bits as its associated LOCK. This requires
213+
a specialized hash function (see proclock_hash).
200214

201215
* Formerly, each PGPROC had a single list of PROCLOCKs belonging to it.
202216
This has now been split into per-partition lists, so that access to a
@@ -226,9 +240,10 @@ deadlock checking should not occur often enough to be performance-critical,
226240
trying to make this work does not seem a productive use of effort.
227241

228242
A backend's internal LOCALLOCK hash table is not partitioned. We do store
229-
the partition number in LOCALLOCK table entries, but this is a straight
230-
speed-for-space tradeoff: we could instead recalculate the partition
231-
number from the LOCKTAG when needed.
243+
a copy of the locktag hash code in LOCALLOCK table entries, from which the
244+
partition number can be computed, but this is a straight speed-for-space
245+
tradeoff: we could instead recalculate the partition number from the LOCKTAG
246+
when needed.
232247

233248

234249
THE DEADLOCK DETECTION ALGORITHM

src/backend/storage/lmgr/deadlock.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@
1212
*
1313
*
1414
* IDENTIFICATION
15-
* $PostgreSQL: pgsql/src/backend/storage/lmgr/deadlock.c,v 1.40 2006/07/14 14:52:23 momjian Exp $
15+
* $PostgreSQL: pgsql/src/backend/storage/lmgr/deadlock.c,v 1.41 2006/07/23 23:08:46 tgl Exp $
1616
*
1717
* Interface:
1818
*
@@ -480,7 +480,7 @@ FindLockCycleRecurse(PGPROC *checkProc,
480480

481481
while (proclock)
482482
{
483-
proc = (PGPROC *) MAKE_PTR(proclock->tag.proc);
483+
proc = proclock->tag.myProc;
484484

485485
/* A proc never blocks itself */
486486
if (proc != checkProc)

0 commit comments

Comments
 (0)