Index: src/backend/storage/lmgr/README
===================================================================
RCS file: /var/lib/cvs/pgsql/src/backend/storage/lmgr/README,v
retrieving revision 1.9
diff -c -r1.9 README
*** src/backend/storage/lmgr/README	29 Sep 2001 04:02:24 -0000	1.9
--- src/backend/storage/lmgr/README	13 Apr 2002 18:49:26 -0000
***************
*** 93,99 ****
      This bitmask indicates what types of locks are currently held on the
      given lockable object.  It is used (against the lock table's conflict
      table) to determine if a new lock request will conflict with existing
!     lock types held.  Conficts are determined by bitwise AND operations
      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.
  
--- 93,99 ----
      This bitmask indicates what types of locks are currently held on the
      given lockable object.  It is used (against the lock table's conflict
      table) to determine if a new lock request will conflict with existing
!     lock types held.  Conflicts are determined by bitwise AND operations
      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.
  
***************
*** 268,274 ****
  of deadlock detection, for two reasons:
  
  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
  with the waiter's request.  This creates no real difficulty however; we
  simply need to be prepared to trace more than one outgoing edge.
  
--- 268,274 ----
  of deadlock detection, for two reasons:
  
  1. A process can be waiting for more than one other process, since there
! might be multiple holders of (non-conflicting) lock types that all conflict
  with the waiter's request.  This creates no real difficulty however; we
  simply need to be prepared to trace more than one outgoing edge.
  
***************
*** 292,298 ****
  
  The workhorse of the deadlock detector is a routine FindLockCycle() which
  is given a starting point process (which must be a waiting process).
! It recursively scans outwards across waits-for edges as discussed above.
  If it finds no cycle involving the start point, it returns "false".
  (As discussed above, we can ignore cycles not involving the start point.)
  When such a cycle is found, FindLockCycle() returns "true", and as it
--- 292,298 ----
  
  The workhorse of the deadlock detector is a routine FindLockCycle() which
  is given a starting point process (which must be a waiting process).
! It recursively scans outward across waits-for edges as discussed above.
  If it finds no cycle involving the start point, it returns "false".
  (As discussed above, we can ignore cycles not involving the start point.)
  When such a cycle is found, FindLockCycle() returns "true", and as it
***************
*** 315,321 ****
  existing entries.  Each soft edge that we are currently considering
  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
! ordering as much as possible, so as not to gratuituously break arrival
  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
  doubly-nested-loop method that emits the first legal candidate at each
--- 315,321 ----
  existing entries.  Each soft edge that we are currently considering
  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
! 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
  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
***************
*** 406,412 ****
  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
  LockWaitCancel (abort a waiter due to outside factors) must run
! ProcLockWakeup, in case the cancelled waiter was soft-blocking other
  waiters.
  
  4. We can minimize excess rearrangement-trial work by being careful to scan
--- 406,412 ----
  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
  LockWaitCancel (abort a waiter due to outside factors) must run
! ProcLockWakeup, in case the canceled waiter was soft-blocking other
  waiters.
  
  4. We can minimize excess rearrangement-trial work by being careful to scan
Index: src/backend/catalog/README
===================================================================
RCS file: /var/lib/cvs/pgsql/src/backend/catalog/README,v
retrieving revision 1.5
diff -c -r1.5 README
*** src/backend/catalog/README	8 Apr 2002 22:09:05 -0000	1.5
--- src/backend/catalog/README	13 Apr 2002 18:49:26 -0000
***************
*** 1,7 ****
  $Header: /var/lib/cvs/pgsql/src/backend/catalog/README,v 1.5 2002/04/08 22:09:05 tgl Exp $
  
! This directory contains .c files that manipulate the system catalogs
! as well as .h files that define the structure of the system catalogs.
  
  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
--- 1,8 ----
  $Header: /var/lib/cvs/pgsql/src/backend/catalog/README,v 1.5 2002/04/08 22:09:05 tgl Exp $
  
! This directory contains .c files that manipulate 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)
  execute, they grep the DATA statements out of the .h files and munge