|
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 $ |
2 | 2 |
|
3 | 3 |
|
4 | 4 | LOCKING OVERVIEW
|
@@ -148,13 +148,21 @@ The lock manager's PROCLOCK objects contain:
|
148 | 148 | tag -
|
149 | 149 | The key fields that are used for hashing entries in the shared memory
|
150 | 150 | 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.) |
152 | 155 |
|
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. |
155 | 158 |
|
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. |
158 | 166 |
|
159 | 167 | holdMask -
|
160 | 168 | 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.
|
191 | 199 | Here are the details:
|
192 | 200 |
|
193 | 201 | * 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). |
200 | 214 |
|
201 | 215 | * Formerly, each PGPROC had a single list of PROCLOCKs belonging to it.
|
202 | 216 | 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,
|
226 | 240 | trying to make this work does not seem a productive use of effort.
|
227 | 241 |
|
228 | 242 | 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. |
232 | 247 |
|
233 | 248 |
|
234 | 249 | THE DEADLOCK DETECTION ALGORITHM
|
|
0 commit comments