Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitc599a24

Browse files
committed
Simplify lock manager data structures by making a clear separation between
the data defining the semantics of a lock method (ie, conflict resolutiontable and ancillary data, which is all constant) and the hash tablesstoring the current state. The only thing we give up by this is theability to use separate hashtables for different lock methods, but thereis no need for that anyway. Put some extra fields into the LockMethoddefinition structs to clean up some other uglinesses, like hard-wiredtests for DEFAULT_LOCKMETHOD and USER_LOCKMETHOD. This commit doesn'tdo anything about the performance issues we were discussing, but it clearsaway some of the underbrush that's in the way of fixing that.
1 parent3484805 commitc599a24

File tree

12 files changed

+396
-576
lines changed

12 files changed

+396
-576
lines changed

‎contrib/userlock/user_locks.c

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,8 @@
2323
(locktag).locktag_field2 = (id1), \
2424
(locktag).locktag_field3 = (id2), \
2525
(locktag).locktag_field4 = 0, \
26-
(locktag).locktag_type = LOCKTAG_USERLOCK)
26+
(locktag).locktag_type = LOCKTAG_USERLOCK, \
27+
(locktag).locktag_lockmethodid = USER_LOCKMETHOD)
2728

2829

2930
int
@@ -33,7 +34,7 @@ user_lock(uint32 id1, uint32 id2, LOCKMODE lockmode)
3334

3435
SET_LOCKTAG_USERLOCK(tag,id1,id2);
3536

36-
return (LockAcquire(USER_LOCKMETHOD,&tag, false,
37+
return (LockAcquire(&tag, false,
3738
lockmode, true, true)!=LOCKACQUIRE_NOT_AVAIL);
3839
}
3940

@@ -44,7 +45,7 @@ user_unlock(uint32 id1, uint32 id2, LOCKMODE lockmode)
4445

4546
SET_LOCKTAG_USERLOCK(tag,id1,id2);
4647

47-
returnLockRelease(USER_LOCKMETHOD,&tag,lockmode, true);
48+
returnLockRelease(&tag,lockmode, true);
4849
}
4950

5051
int

‎src/backend/storage/ipc/ipci.c

Lines changed: 2 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $PostgreSQL: pgsql/src/backend/storage/ipc/ipci.c,v 1.79 2005/10/15 02:49:25 momjian Exp $
11+
* $PostgreSQL: pgsql/src/backend/storage/ipc/ipci.c,v 1.80 2005/12/09 01:22:03 tgl Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -25,7 +25,7 @@
2525
#include"storage/bufmgr.h"
2626
#include"storage/freespace.h"
2727
#include"storage/ipc.h"
28-
#include"storage/lmgr.h"
28+
#include"storage/lock.h"
2929
#include"storage/lwlock.h"
3030
#include"storage/pg_sema.h"
3131
#include"storage/pg_shmem.h"
@@ -159,7 +159,6 @@ CreateSharedMemoryAndSemaphores(bool makePrivate, int port)
159159
* Set up lock manager
160160
*/
161161
InitLocks();
162-
InitLockTable();
163162

164163
/*
165164
* Set up process table

‎src/backend/storage/lmgr/README

Lines changed: 25 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
$PostgreSQL: pgsql/src/backend/storage/lmgr/README,v 1.17 2005/06/1422:15:32 tgl Exp $
1+
$PostgreSQL: pgsql/src/backend/storage/lmgr/README,v 1.18 2005/12/09 01:22:04 tgl Exp $
22

33

44
LOCKING OVERVIEW
@@ -151,7 +151,7 @@ tag -
151151
SHMEM offset of the LOCK object this PROCLOCK is for.
152152

153153
tag.proc
154-
SHMEM offset ofPROC of backend process that owns this PROCLOCK.
154+
SHMEM offset ofPGPROC of backend process that owns this PROCLOCK.
155155

156156
holdMask -
157157
A bitmask for the lock types successfully acquired by this PROCLOCK.
@@ -415,3 +415,26 @@ seems a safer approach than trying to allocate workspace on the fly; we
415415
don't want to risk having the deadlock detector run out of memory, else
416416
we really have no guarantees at all that deadlock will be detected.
417417

418+
419+
USER LOCKS
420+
421+
User locks are handled totally on the application side as long term
422+
cooperative locks which extend beyond the normal transaction boundaries.
423+
Their purpose is to indicate to an application that someone is `working'
424+
on an item. So it is possible to put an user lock on a tuple's oid,
425+
retrieve the tuple, work on it for an hour and then update it and remove
426+
the lock. While the lock is active other clients can still read and write
427+
the tuple but they can be aware that it has been locked at the application
428+
level by someone.
429+
430+
User locks and normal locks are completely orthogonal and they don't
431+
interfere with each other.
432+
433+
User locks are always non blocking, therefore they are never acquired if
434+
already held by another process. They must be released explicitly by the
435+
application but they are released automatically when a backend terminates.
436+
437+
The lockmode parameter can have the same values as for normal locks although
438+
probably only ExclusiveLock can have some practical use.
439+
440+
DZ - 22 Nov 1997

‎src/backend/storage/lmgr/deadlock.c

Lines changed: 3 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.36 2005/10/29 00:31:51 petere Exp $
15+
* $PostgreSQL: pgsql/src/backend/storage/lmgr/deadlock.c,v 1.37 2005/12/09 01:22:04 tgl Exp $
1616
*
1717
*Interface:
1818
*
@@ -930,7 +930,8 @@ DeadLockReport(void)
930930
appendStringInfo(&buf,
931931
_("Process %d waits for %s on %s; blocked by process %d."),
932932
info->pid,
933-
GetLockmodeName(info->lockmode),
933+
GetLockmodeName(info->locktag.locktag_lockmethodid,
934+
info->lockmode),
934935
buf2.data,
935936
nextpid);
936937
}

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp