Make source code READMEs more consistent. Add CVS tags to all README files.

src/backend/access/gin/README

@@ -1,3 +1,5 @@
+$PostgreSQL: pgsql/src/backend/access/gin/README,v 1.5 2008/03/20 17:55:14 momjian Exp $
+
 Gin for PostgreSQL
 ==================
 

src/backend/access/gist/README

@@ -1,4 +1,7 @@
-$PostgreSQL: pgsql/src/backend/access/gist/README,v 1.3 2005/09/16 14:40:54 teodor Exp $
+$PostgreSQL: pgsql/src/backend/access/gist/README,v 1.4 2008/03/20 17:55:14 momjian Exp $
+
+GiST Indexing
+=============
 
 This directory contains an implementation of GiST indexing for Postgres.
 
@@ -48,7 +51,8 @@ core and PostgreSQL WAL system. Moreover, we encountered (and solved)
 a problem of uncompleted insertions when recovering after crash, which
 was not touched in the paper.
 
-SEARCH ALGORITHM
+Search Algorithm
+----------------
 
 Function gettuple finds a tuple which satisfies the search
 predicate. It store their state and returns next tuple under
@@ -92,7 +96,8 @@ gettuple(search-pred)
 	end
 
 
-INSERT ALGORITHM
+Insert Algorithm
+----------------
 
 INSERT guarantees that the GiST tree remains balanced. User defined key method 
 Penalty is used for choosing a subtree to insert; method PickSplit is used for 

src/backend/access/hash/README

@@ -1,4 +1,7 @@
-$PostgreSQL: pgsql/src/backend/access/hash/README,v 1.7 2008/03/15 20:46:31 tgl Exp $
+$PostgreSQL: pgsql/src/backend/access/hash/README,v 1.8 2008/03/20 17:55:14 momjian Exp $
+
+Hash Indexing
+=============
 
 This directory contains an implementation of hash indexing for Postgres.  Most
 of the core ideas are taken from Margo Seltzer and Ozan Yigit, A New Hashing
@@ -30,7 +33,7 @@ in other buckets, but we never give them back to the operating system.
 There is no provision for reducing the number of buckets, either.
 
 
-Page addressing
+Page Addressing
 ---------------
 
 There are four kinds of pages in a hash index: the meta page (page zero),
@@ -111,7 +114,7 @@ first bitmap page, which is allocated during index creation just after all
 the initially created buckets.
 
 
-Lock definitions
+Lock Definitions
 ----------------
 
 We use both lmgr locks ("heavyweight" locks) and buffer context locks
@@ -166,7 +169,7 @@ be held at a time by any one process.  (The third restriction is probably
 stronger than necessary, but it makes the proof of no deadlock obvious.)
 
 
-Pseudocode algorithms
+Pseudocode Algorithms
 ---------------------
 
 The operations we need to support are: readers scanning the index for
@@ -324,7 +327,7 @@ The exclusive lock request could deadlock in some strange scenarios, but
 we can just error out without any great harm being done.
 
 
-Free space management
+Free Space Management
 ---------------------
 
 (Question: why is this so complicated?  Why not just have a linked list
@@ -429,7 +432,7 @@ All the freespace operations should be called while holding no buffer
 locks.  Since they need no lmgr locks, deadlock is not possible.
 
 
-Other notes
+Other Notes
 -----------
 
 All the shenanigans with locking prevent a split occurring while *another*

src/backend/access/nbtree/README

@@ -1,4 +1,7 @@
-$PostgreSQL: pgsql/src/backend/access/nbtree/README,v 1.18 2007/09/12 22:10:26 tgl Exp $
+$PostgreSQL: pgsql/src/backend/access/nbtree/README,v 1.19 2008/03/20 17:55:14 momjian Exp $
+
+Btree Indexing
+--------------
 
 This directory contains a correct implementation of Lehman and Yao's
 high-concurrency B-tree management algorithm (P. Lehman and S. Yao,
@@ -8,7 +11,7 @@ use a simplified version of the deletion logic described in Lanin and
 Shasha (V. Lanin and D. Shasha, A Symmetric Concurrent B-Tree Algorithm,
 Proceedings of 1986 Fall Joint Computer Conference, pp 380-389).
 
-The Lehman and Yao algorithm and insertions
+The Lehman and Yao Algorithm and Insertions
 -------------------------------------------
 
 We have made the following changes in order to incorporate the L&Y algorithm
@@ -125,7 +128,7 @@ each of the resulting pages.  Note we must include the incoming item in
 this calculation, otherwise it is possible to find that the incoming
 item doesn't fit on the split page where it needs to go!
 
-The deletion algorithm
+The Deletion Algorithm
 ----------------------
 
 Before deleting a leaf item, we get a super-exclusive lock on the target
@@ -320,7 +323,7 @@ positives, so long as it never gives a false negative.  This makes it
 possible to implement the test with a small counter value stored on each
 index page.
 
-On-the-fly deletion of index tuples
+On-the-Fly Deletion Of Index Tuples
 -----------------------------------
 
 If a process visits a heap tuple and finds that it's dead and removable
@@ -357,7 +360,7 @@ and so cannot remove the heap tuple.  This is another reason why
 btbulkdelete has to get super-exclusive lock on every leaf page, not only
 the ones where it actually sees items to delete.
 
-WAL considerations
+WAL Considerations
 ------------------
 
 The insertion and deletion algorithms in themselves don't guarantee btree
@@ -398,7 +401,7 @@ of the WAL entry.)  If the parent page becomes half-dead but is not
 immediately deleted due to a subsequent crash, there is no loss of
 consistency, and the empty page will be picked up by the next VACUUM.
 
-Other things that are handy to know
+Other Things That Are Handy to Know
 -----------------------------------
 
 Page zero of every btree is a meta-data page.  This page stores the
@@ -443,7 +446,7 @@ original search scankey is consulted as each index entry is sequentially
 scanned to decide whether to return the entry and whether the scan can
 stop (see _bt_checkkeys()).
 
-Notes about data representation
+Notes About Data Representation
 -------------------------------
 
 The right-sibling link required by L&Y is kept in the page "opaque
@@ -477,7 +480,7 @@ item is irrelevant, and need not be stored at all.  This arrangement
 corresponds to the fact that an L&Y non-leaf page has one more pointer
 than key.
 
-Notes to operator class implementors
+Notes to Operator Class Implementors
 ------------------------------------
 
 With this implementation, we require each supported combination of

src/backend/access/transam/README

@@ -1,4 +1,4 @@
-$PostgreSQL: pgsql/src/backend/access/transam/README,v 1.9 2007/09/08 20:31:14 tgl Exp $
+$PostgreSQL: pgsql/src/backend/access/transam/README,v 1.10 2008/03/20 17:55:14 momjian Exp $
 
 The Transaction System
 ----------------------
@@ -145,7 +145,7 @@ finishing of transactions and subtransactions.  For example, AtStart_Memory
 takes care of initializing the memory subsystem at main transaction start.
 
 
-Subtransaction handling
+Subtransaction Handling
 -----------------------
 
 Subtransactions are implemented using a stack of TransactionState structures,
@@ -187,7 +187,7 @@ Another difference is that BeginInternalSubtransaction is allowed when no
 explicit transaction block has been established, while DefineSavepoint is not.
 
 
-Transaction and subtransaction numbering
+Transaction and Subtransaction Numbering
 ----------------------------------------
 
 Transactions and subtransactions are assigned permanent XIDs only when/if
@@ -221,7 +221,7 @@ InvalidSubTransactionId.)  Note that subtransactions do not have their
 own VXIDs; they use the parent top transaction's VXID.
 
 
-Interlocking transaction begin, transaction end, and snapshots
+Interlocking Transaction Begin, Transaction End, and Snapshots
 --------------------------------------------------------------
 
 We try hard to minimize the amount of overhead and lock contention involved
@@ -375,7 +375,7 @@ for pg_clog are implemented in transam.c, while the low-level functions are in
 clog.c.  pg_subtrans is contained completely in subtrans.c.
 
 
-Write-Ahead Log coding
+Write-Ahead Log Coding
 ----------------------
 
 The WAL subsystem (also called XLOG in the code) exists to guarantee crash