Fix spelling and file markers in resource scheduling/queue

Fixed a few spelling errors, and minor whitespace issues, in the
Resource Scheduling README while reading it. Also updated the file
markers on the README, Makefile and code to match upstream CVS to
Git conversion. No semantic changes made to the text.

src/backend/commands/queue.c

@@ -7,7 +7,8 @@
  * Portions Copyright (c) 1996-2008, PostgreSQL Global Development Group
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $PostgreSQL$
+ * IDENTIFICATION
+ *    src/backend/commands/queue.c
  *
  *-------------------------------------------------------------------------
  */

src/backend/utils/resscheduler/Makefile

@@ -4,7 +4,7 @@
 #    Makefile for utils/resscheduler
 #
 # IDENTIFICATION
-#    $PostgreSQL$
+#    src/backend/utils/resscheduler/Makefile
 #
 #-------------------------------------------------------------------------
 

src/backend/utils/resscheduler/README

-$PostgreSQL$
+src/backend/utils/resscheduler/README
 
 Resource Scheduling
 ===================
@@ -19,22 +19,22 @@ The basic design makes use of data structures from the standard lock
 implementation, but adapts them to handle the differing semantics required
 for tracking transient resources.
 
-A psuedo E-R diagram for the various resource scheduling objects is:
+A pseudo E-R diagram for the various resource scheduling objects is:
 
 
 role >---- resource queue ----< limits
               |
               |
-            queue  ----< limit thresholds, limit values 
+            queue  ----< limit thresholds, limit values
               |
               |
            lock ----- proclock -----------------+
                         |                       |
                         |                       ^
                       proc ---< portal ----< portal increment
-                                                 
 
-The objects that are additional to the standard lock system are are described 
+
+The objects that are additional to the standard lock system are described
 below:
 
 Limits -
@@ -42,11 +42,10 @@ Limits -
     current utilization and a type.
 
 Queues -
-    A queue consists of a set of limits. It also has some attributes of its 
+    A queue consists of a set of limits. It also has some attributes of its
     own - a flag for whether queries whose cost is > the cost limit will be
     allowed to run (under special circumstances) and a special limit that
     allows queries with a small cost to avoid being locked at all.
-    
 
 Resource Lock -
     The lock related information for a queue, each queue has 1 and only 1
@@ -56,10 +55,10 @@ Portal Increment -
     The resource related information for a statement. This consists of the
     process id, portal id and the set of additional changes to the limit
     counters that will be applied should this portal execute. A portal that
-    is managed by the scheduler [1] *always* has increments - portals for 
-    queries that are not going to be locked have portalId set to InvalidOid 
-    (either because the owning role is not in a queue or the query has cost 
-    smaller than the queue's "ignore" limit - see Queues above). 
+    is managed by the scheduler [1] *always* has increments - portals for
+    queries that are not going to be locked have portalId set to InvalidOid
+    (either because the owning role is not in a queue or the query has cost
+    smaller than the queue's "ignore" limit - see Queues above).
 
 Proclock -
      Some changes have been made to the proclock structure... this should be
@@ -83,8 +82,8 @@ The basic API consists of:
     ResUnLockPortal(Portal portal);
 
 which are inserted into PortalStart and PortalDrop respectively. In PortalStart
-the ResLockPortal call is made after planning is completed, so there is access 
-to all elements of the plan structure, thus controlling resources on the basis 
+the ResLockPortal call is made after planning is completed, so there is access
+to all elements of the plan structure, thus controlling resources on the basis
 of cost is possible.
 
 As the resource lock is taken after parse/analyze most standard locks have
@@ -103,7 +102,7 @@ increments to the replacement for the Conflict routines:
                       ResPortalIncrement *incrementSet,
                       bool increment);
 
-This function encapsulates the fact that resource lock conflict is not 
+This function encapsulates the fact that resource lock conflict is not
 deterministic, but depends on whether current limit counter values are at their
 thresholds. If there is not a conflict, a statement's increments are added (or
 subtracted) to the shared counters by:
@@ -114,24 +113,24 @@ subtracted) to the shared counters by:
 
 Commit and Abort handling is mostly handled from the existing ResourceOwner
 code - as dropping portals unlocks them! However for WITH HOLD cursors an
-extra function to unlock any remaining portals at sesion exit is required:
+extra function to unlock any remaining portals at session exit is required:
 
     AtExitCleanup_ResPortals(void);
 
-Some of the standard lock manager code is almost duplicated to handle interrupts
-,sleeping and wait queue removal:
+Some of the standard lock manager code is almost duplicated to handle
+interrupts, sleeping and wait queue removal:
 
     ResLockWaitCancel(void);
     ResProcSleep(LOCKMODE lockmode, LOCALLOCK *locallock):
     ResRemoveFromWaitQueue(PGPROC *proc, uint32 hashcode);
 
 Deadlocks between standard and resource locks are possible, and are handled
-by the deadlock detector. We pass the lock mode as ExclusiveLock - which 
-results in overly agressive detection and rollback of deadocks. However, safety
+by the deadlock detector. We pass the lock mode as ExclusiveLock - which
+results in overly agressive detection and rollback of deadlocks. However, safety
 is the *initial* goal! More sophisticated detection logic is an obvious next
 step.
 
-Also deadlocks with oneself are possible, usually only achiveable with several
+Also deadlocks with oneself are possible, usually only achievable with several
 open cursors:
     ResCheckSelfDeadLock(LOCK *lock);
 -----------------------------------------------------------------------------
@@ -139,15 +138,15 @@ open cursors:
 Lock Design
 -----------
 
-The resource locks share the lock hash table(s) with the standard (and user) 
-locks. This means that they use the standard lock manager partitioned 
-lightweight lock(s): 
+The resource locks share the lock hash table(s) with the standard (and user)
+locks. This means that they use the standard lock manager partitioned
+lightweight lock(s):
 
-  FirstLockMgrLock,..., FirstLockMgrLock + NUM_LOCK_PARTITIONS 
+  FirstLockMgrLock,..., FirstLockMgrLock + NUM_LOCK_PARTITIONS
 
-for lightweight lock operations. 
+for lightweight lock operations.
 
-The queues themselves and their data are protected by a seperate lightweight 
+The queues themselves and their data are protected by a separate lightweight
 lock:
 
   ResQueueLock
@@ -172,13 +171,13 @@ Some new commands are added and others amended to allow administration of the
 resource queues:
 
 Queues can be created, altered and dropped via the CREATE|ALTER|DROP QUEUE
-commands. 
+commands.
 
-CREATE RESOURCE QUEUE <name> [ACTIVE THRESHOLD <int value>] 
+CREATE RESOURCE QUEUE <name> [ACTIVE THRESHOLD <int value>]
                              [COST THRESHOLD <float value>]
                              [IGNORE THRESHOLD <float value>]
                              [OVERCOMMIT|NOOVERCOMMIT];
-ALTER RESOURCE QUEUE <name>  [ACTIVE THRESHOLD <int value>] 
+ALTER RESOURCE QUEUE <name>  [ACTIVE THRESHOLD <int value>]
                              [COST THRESHOLD <float value>]
                              [IGNORE THRESHOLD <float value>]
                              [OVERCOMMIT|NOOVERCOMMIT];
@@ -193,19 +192,19 @@ The ignore threshold sets a lower limit for queries to be locked for execution -
 query cost < this limit means locking will be skipped.
 The overcommit parameter controls what happens for a query whose cost > cost
 limit for the queue - it either aborts (the default) or waits until noone else
-is executing. This is to avoid the situation of querys being in the wait state 
+is executing. This is to avoid the situation of querys being in the wait state
 forever.
 These last two parameters complicate the logic considerably, needless to say!
 
-The ALTER RESOURCE QUEUE command will only allow the thresholds to be amended 
-to a value larger than the current counter for the in-memory queues. This is a 
+The ALTER RESOURCE QUEUE command will only allow the thresholds to be amended
+to a value larger than the current counter for the in-memory queues. This is a
 safety feature to prevent unexpected behaviour.
 
 The DROP RESOURCE command does not allow queues to be dropped if there are roles
-assigned to it, It does not allow it to be dropped unless all of the current 
-values for the in-memory queue are zero. 
+assigned to it. It is neither allowed to be dropped unless all of the current
+values for the in-memory queue are zero.
 
-Only superuser can create, alter or drop resource queues.
+Only superusers can create, alter or drop resource queues.
 
 
 Roles are assigned to and removed from the resource queues by CREATE|ALTER ROLE
@@ -222,7 +221,7 @@ The resource queue name 'none' is used to mean 'no resource queue thanks'.
 Catalog Changes
 ---------------
 
-Resource Scheduling add one new catalog (pg_resqueue) and alters another 
+Resource Scheduling add one new catalog (pg_resqueue) and alters another
 (pg_authid). This alteration is propagated to the derived view (pg_roles).
 
 The new catalog and indexes have not been added to the catcache system.
@@ -265,7 +264,7 @@ Debugging Code
 --------------
 
 There are a number of (hopefully) helpful elog messages at the DEBUG1 level -
-however the symbol RESLOCK_DEBUG must be defined before they are enabled 
+however the symbol RESLOCK_DEBUG must be defined before they are enabled
 (usually done in src/include/pg_config_manual.h)
 
 -----------------------------------------------------------------------------
@@ -279,7 +278,6 @@ Notes
        portal->queueId != InvalidOid
        portal->releaseResLock == true
 
-     
-     Typically every portal gets queueId set at creation, but this may get 
-     reset when the to-lock-or-not-to-lock decision comes around (see 
+     Typically every portal gets queueId set at creation, but this may get
+     reset when the to-lock-or-not-to-lock decision comes around (see
      ResLockPortal).