rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Minor corrections in lmgr/README. 

Correct an obsolete statement that no backend touches another backend's
PROCLOCK lists.  This was probably wrong even when written (the deadlock
checker looks at everybody's lists), and it's certainly quite wrong now
that fast-path locking can require creation of lock and proclock objects
on behalf of another backend.  Also improve some statements in the hot
standby explanation, and do one or two other trivial bits of wordsmithing/
reformatting.
This commit is contained in:
Tom Lane 2013-11-27 15:07:13 -05:00
parent 631118fe1e
commit 8c84803e14
1 changed files with 33 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
src/backend/storage/lmgr/README
View File

@ -228,14 +228,9 @@ a specialized hash function (see proclock_hash).
* Formerly, each PGPROC had a single list of PROCLOCKs belonging to it.
This has now been split into per-partition lists, so that access to a
particular PROCLOCK list can be protected by the associated partition's
LWLock. (This is not strictly necessary at the moment, because at this
writing a PGPROC's PROCLOCK list is only accessed by the owning backend
anyway. But it seems forward-looking to maintain a convention for how
other backends could access it. In any case LockReleaseAll needs to be
able to quickly determine which partition each LOCK belongs to, and
for the currently contemplated number of partitions, this way takes less
shared memory than explicitly storing a partition number in LOCK structs
would require.)
LWLock. (This rule allows one backend to manipulate another backend's
PROCLOCK lists, which was not originally necessary but is now required in
connection with fast-path locking; see below.)
* The other lock-related fields of a PGPROC are only interesting when
the PGPROC is waiting for a lock, so we consider that they are protected
@ -292,20 +287,20 @@ To alleviate this bottleneck, beginning in PostgreSQL 9.2, each backend is
permitted to record a limited number of locks on unshared relations in an
array within its PGPROC structure, rather than using the primary lock table.
This mechanism can only be used when the locker can verify that no conflicting
locks can possibly exist.
locks exist at the time of taking the lock.
A key point of this algorithm is that it must be possible to verify the
absence of possibly conflicting locks without fighting over a shared LWLock or
spinlock. Otherwise, this effort would simply move the contention bottleneck
from one place to another. We accomplish this using an array of 1024 integer
counters, which are in effect a 1024-way partitioning of the lock space. Each
counter records the number of "strong" locks (that is, ShareLock,
counters, which are in effect a 1024-way partitioning of the lock space.
Each counter records the number of "strong" locks (that is, ShareLock,
ShareRowExclusiveLock, ExclusiveLock, and AccessExclusiveLock) on unshared
relations that fall into that partition. When this counter is non-zero, the
fast path mechanism may not be used for relation locks in that partition. A
strong locker bumps the counter and then scans each per-backend array for
matching fast-path locks; any which are found must be transferred to the
primary lock table before attempting to acquire the lock, to ensure proper
fast path mechanism may not be used to take new relation locks within that
partition. A strong locker bumps the counter and then scans each per-backend
array for matching fast-path locks; any which are found must be transferred to
the primary lock table before attempting to acquire the lock, to ensure proper
lock conflict and deadlock detection.
On an SMP system, we must guarantee proper memory synchronization. Here we
@ -314,19 +309,19 @@ A performs a store, A and B both acquire an LWLock in either order, and B
then performs a load on the same memory location, it is guaranteed to see
A's store. In this case, each backend's fast-path lock queue is protected
by an LWLock. A backend wishing to acquire a fast-path lock grabs this
LWLock before examining FastPathStrongRelationLocks to check for the presence of
a conflicting strong lock. And the backend attempting to acquire a strong
LWLock before examining FastPathStrongRelationLocks to check for the presence
of a conflicting strong lock. And the backend attempting to acquire a strong
lock, because it must transfer any matching weak locks taken via the fast-path
mechanism to the shared lock table, will acquire every LWLock protecting
a backend fast-path queue in turn. So, if we examine FastPathStrongRelationLocks
and see a zero, then either the value is truly zero, or if it is a stale value,
the strong locker has yet to acquire the per-backend LWLock we now hold (or,
indeed, even the first per-backend LWLock) and will notice any weak lock we
take when it does.
mechanism to the shared lock table, will acquire every LWLock protecting a
backend fast-path queue in turn. So, if we examine
FastPathStrongRelationLocks and see a zero, then either the value is truly
zero, or if it is a stale value, the strong locker has yet to acquire the
per-backend LWLock we now hold (or, indeed, even the first per-backend LWLock)
and will notice any weak lock we take when it does.
Fast-path VXID locks do not use the FastPathStrongRelationLocks table. The
first lock taken on a VXID is always the ExclusiveLock taken by its owner. Any
subsequent lockers are share lockers waiting for the VXID to terminate.
first lock taken on a VXID is always the ExclusiveLock taken by its owner.
Any subsequent lockers are share lockers waiting for the VXID to terminate.
Indeed, the only reason VXID locks use the lock manager at all (rather than
waiting for the VXID to terminate via some other method) is for deadlock
detection. Thus, the initial VXID lock can *always* be taken via the fast
@ -335,6 +330,10 @@ whether the lock has been transferred to the main lock table, and if not,
do so. The backend owning the VXID must be careful to clean up any entry
made in the main lock table at end of transaction.
Deadlock detection does not need to examine the fast-path data structures,
because any lock that could possibly be involved in a deadlock must have
been transferred to the main tables beforehand.
The Deadlock Detection Algorithm
--------------------------------
@ -376,7 +375,7 @@ inserted in the wait queue just ahead of the first such waiter. (If we
did not make this check, the deadlock detection code would adjust the
queue order to resolve the conflict, but it's relatively cheap to make
the check in ProcSleep and avoid a deadlock timeout delay in this case.)
Note special case when inserting before the end of the queue: if the
Note special case when inserting before the end of the queue: if the
process's request does not conflict with any existing lock nor any
waiting request before its insertion point, then go ahead and grant the
lock without waiting.
@ -414,7 +413,7 @@ need to kill all the transactions involved.
indicates a deadlock, but one that does not involve our starting
process. We ignore this condition on the grounds that resolving such a
deadlock is the responsibility of the processes involved --- killing our
start- point process would not resolve the deadlock. So, cases 1 and 3
start-point process would not resolve the deadlock. So, cases 1 and 3
both report "no deadlock".
Postgres' situation is a little more complex than the standard discussion
@ -620,7 +619,7 @@ level is AccessExclusiveLock.
Regular backends are only allowed to take locks on relations or objects
at RowExclusiveLock or lower. This ensures that they do not conflict with
each other or with the Startup process, unless AccessExclusiveLocks are
requested by one of the backends.
requested by the Startup process.
Deadlocks involving AccessExclusiveLocks are not possible, so we need
not be concerned that a user initiated deadlock can prevent recovery from
@ -632,3 +631,9 @@ of transaction just as they are in normal processing. These locks are
held by the Startup process, acting as a proxy for the backends that
originally acquired these locks. Again, these locks cannot conflict with
one another, so the Startup process cannot deadlock itself either.
Although deadlock is not possible, a regular backend's weak lock can
prevent the Startup process from making progress in applying WAL, which is
usually not something that should be tolerated for very long. Mechanisms
exist to forcibly cancel a regular backend's query if it blocks the
Startup process for too long.