database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-01 14:21:49 +03:00
Code

The attached patch corrects an inaccuracy in src/backend/catalog/README

Browse Source 
and fixes a few spelling mistakes in src/bakckend/lmgr/README.

Neil Conway
This commit is contained in:
Bruce Momjian 2002-04-15 23:46:13 +00:00
parent bbae09c2cb
commit 33d1bb76c6
2 changed files with 10 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
src/backend/catalog/README
View File

@ -1,7 +1,8 @@
$Header: /cvsroot/pgsql/src/backend/catalog/README,v 1.5 2002/04/08 22:09:05 tgl Exp $ $Header: /cvsroot/pgsql/src/backend/catalog/README,v 1.6 2002/04/15 23:46:13 momjian Exp $
This directory contains .c files that manipulate the system catalogs This directory contains .c files that manipulate the system catalogs;
as well as .h files that define the structure of the system catalogs. src/include/catalog contains the .h files that define the structure
of the system catalogs.
When the compile-time scripts (such as Gen_fmgrtab.sh and genbki.sh) When the compile-time scripts (such as Gen_fmgrtab.sh and genbki.sh)
execute, they grep the DATA statements out of the .h files and munge execute, they grep the DATA statements out of the .h files and munge

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

@ -1,4 +1,4 @@
$Header: /cvsroot/pgsql/src/backend/storage/lmgr/README,v 1.9 2001/09/29 04:02:24 tgl Exp $ $Header: /cvsroot/pgsql/src/backend/storage/lmgr/README,v 1.10 2002/04/15 23:46:13 momjian Exp $
LOCKING OVERVIEW LOCKING OVERVIEW
@ -93,7 +93,7 @@ grantMask -
This bitmask indicates what types of locks are currently held on the This bitmask indicates what types of locks are currently held on the
given lockable object. It is used (against the lock table's conflict given lockable object. It is used (against the lock table's conflict
table) to determine if a new lock request will conflict with existing table) to determine if a new lock request will conflict with existing
lock types held. Conficts are determined by bitwise AND operations lock types held. Conflicts are determined by bitwise AND operations
between the grantMask and the conflict table entry for the requested between the grantMask and the conflict table entry for the requested
lock type. Bit i of grantMask is 1 if and only if granted[i] > 0. lock type. Bit i of grantMask is 1 if and only if granted[i] > 0.
@ -268,7 +268,7 @@ Postgres' situation is a little more complex than the standard discussion
of deadlock detection, for two reasons: of deadlock detection, for two reasons:
1. A process can be waiting for more than one other process, since there 1. A process can be waiting for more than one other process, since there
might be multiple holders of (nonconflicting) lock types that all conflict might be multiple holders of (non-conflicting) lock types that all conflict
with the waiter's request. This creates no real difficulty however; we with the waiter's request. This creates no real difficulty however; we
simply need to be prepared to trace more than one outgoing edge. simply need to be prepared to trace more than one outgoing edge.
@ -292,7 +292,7 @@ algorithm.
The workhorse of the deadlock detector is a routine FindLockCycle() which The workhorse of the deadlock detector is a routine FindLockCycle() which
is given a starting point process (which must be a waiting process). is given a starting point process (which must be a waiting process).
It recursively scans outwards across waits-for edges as discussed above. It recursively scans outward across waits-for edges as discussed above.
If it finds no cycle involving the start point, it returns "false". If it finds no cycle involving the start point, it returns "false".
(As discussed above, we can ignore cycles not involving the start point.) (As discussed above, we can ignore cycles not involving the start point.)
When such a cycle is found, FindLockCycle() returns "true", and as it When such a cycle is found, FindLockCycle() returns "true", and as it
@ -315,7 +315,7 @@ We build a proposed new queue order by doing a "topological sort" of the
existing entries. Each soft edge that we are currently considering existing entries. Each soft edge that we are currently considering
reversing creates a property of the partial order that the topological sort reversing creates a property of the partial order that the topological sort
has to enforce. We must use a sort method that preserves the input has to enforce. We must use a sort method that preserves the input
ordering as much as possible, so as not to gratuituously break arrival ordering as much as possible, so as not to gratuitously break arrival
order for processes not involved in a deadlock. (This is not true of the order for processes not involved in a deadlock. (This is not true of the
tsort method shown in Knuth, for example, but it's easily done by a simple tsort method shown in Knuth, for example, but it's easily done by a simple
doubly-nested-loop method that emits the first legal candidate at each doubly-nested-loop method that emits the first legal candidate at each
@ -406,7 +406,7 @@ implementation, BTW). Therefore, if ProcLockWakeup is always invoked
after a lock is released or a wait queue is rearranged, there can be no after a lock is released or a wait queue is rearranged, there can be no
failure to wake a wakable process. One should also note that failure to wake a wakable process. One should also note that
LockWaitCancel (abort a waiter due to outside factors) must run LockWaitCancel (abort a waiter due to outside factors) must run
ProcLockWakeup, in case the cancelled waiter was soft-blocking other ProcLockWakeup, in case the canceled waiter was soft-blocking other
waiters. waiters.
4. We can minimize excess rearrangement-trial work by being careful to scan 4. We can minimize excess rearrangement-trial work by being careful to scan