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

Author: bmomjian

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

src/backend/catalog/README

@@ -1,4 +1,7 @@
-$PostgreSQL: pgsql/src/backend/catalog/README,v 1.11 2007/05/11 17:57:11 tgl Exp $
+$PostgreSQL: pgsql/src/backend/catalog/README,v 1.12 2008/03/20 17:55:14 momjian Exp $
+
+System Catalog
+--------------
 
 This directory contains .c files that manipulate the system catalogs;
 src/include/catalog contains the .h files that define the structure

src/backend/executor/README

@@ -1,4 +1,4 @@
-$PostgreSQL: pgsql/src/backend/executor/README,v 1.5 2005/04/28 21:47:12 tgl Exp $
+$PostgreSQL: pgsql/src/backend/executor/README,v 1.6 2008/03/20 17:55:14 momjian Exp $
 
 The Postgres Executor
 ---------------------
@@ -137,7 +137,7 @@ be hidden inside function calls).  This case has a flow of control like
 		(a separate FreeExprContext call is not necessary)
 
 
-EvalPlanQual (READ COMMITTED update checking)
+EvalPlanQual (READ COMMITTED Update Checking)
 ---------------------------------------------
 
 For simple SELECTs, the executor need only pay attention to tuples that are

src/backend/nodes/README

@@ -1,15 +1,12 @@
-*******************************************************************************
-*                                                                             *
-* EXPLANATION OF THE NODE STRUCTURES                                          *
-*    - Andrew Yu (11/94)                                                      *
-*                                                                             *
-* Copyright (c) 1994, Regents of the University of California                 *
-*                                                                             *
-* $PostgreSQL: pgsql/src/backend/nodes/README,v 1.2 2003/11/29 22:39:45 pgsql Exp $
-*                                                                             *
-*******************************************************************************
-
-INTRODUCTION
+$PostgreSQL: pgsql/src/backend/nodes/README,v 1.3 2008/03/20 17:55:14 momjian Exp $
+
+Node Structures
+===============
+
+Andrew Yu (11/94)
+
+Introduction
+------------
 
 The current node structures are plain old C structures. "Inheritance" is
 achieved by convention. No additional functions will be generated. Functions
@@ -36,7 +33,8 @@ FILES IN THIS DIRECTORY
 	memnodes.h	- memory nodes
 
 
-STEPS TO ADD A NODE
+Steps to Add a Node
+-------------------
 
 Suppose you wana define a node Foo:
 
@@ -51,7 +49,8 @@ Suppose you wana define a node Foo:
    bother writing a creator function in makefuncs.c)
 
 
-HISTORICAL NOTE
+Historical Note
+---------------
 
 Prior to the current simple C structure definitions, the Node structures 
 uses a pseudo-inheritance system which automatically generates creator and

src/backend/optimizer/README

@@ -1,5 +1,7 @@
-Summary
--------
+$PostgreSQL: pgsql/src/backend/optimizer/README,v 1.42 2008/03/20 17:55:14 momjian Exp $
+
+Optimizer
+---------
 
 These directories take the Query structure returned by the parser, and
 generate a plan used by the executor.  The /plan directory generates the
@@ -180,7 +182,7 @@ to see which join style should be applied for a valid join, ie,
 JOIN_INNER, JOIN_LEFT, etc.)
 
 
-Valid OUTER JOIN optimizations
+Valid OUTER JOIN Optimizations
 ------------------------------
 
 The planner's treatment of outer join reordering is based on the following
@@ -236,7 +238,7 @@ set must be expanded to include the whole of the lower OJ, thereby
 preventing it from being formed before the lower OJ is.)
 
 
-Pulling up subqueries
+Pulling Up Subqueries
 ---------------------
 
 As we described above, a subquery appearing in the range table is planned

src/backend/optimizer/plan/README

@@ -1,12 +1,16 @@
-Subselect notes from Vadim.
+$PostgreSQL: pgsql/src/backend/optimizer/plan/README,v 1.2 2008/03/20 17:55:14 momjian Exp $
 
+Subselects
+----------
+
+Vadim B. Mikheev
 
 
 From owner-pgsql-hackers@hub.org Fri Feb 13 09:01:19 1998
 Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
 	by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id JAA11576
 	for <maillist@candle.pha.pa.us>; Fri, 13 Feb 1998 09:01:17 -0500 (EST)
-Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$Revision: 1.1 $) with ESMTP id IAA09761 for <maillist@candle.pha.pa.us>; Fri, 13 Feb 1998 08:41:22 -0500 (EST)
+Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$Revision: 1.2 $) with ESMTP id IAA09761 for <maillist@candle.pha.pa.us>; Fri, 13 Feb 1998 08:41:22 -0500 (EST)
 Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id IAA08135; Fri, 13 Feb 1998 08:40:17 -0500 (EST)
 Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Fri, 13 Feb 1998 08:38:42 -0500 (EST)
 Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id IAA06646 for pgsql-hackers-outgoing; Fri, 13 Feb 1998 08:38:35 -0500 (EST)

src/backend/parser/README

@@ -1,3 +1,8 @@
+$PostgreSQL: pgsql/src/backend/parser/README,v 1.6 2008/03/20 17:55:14 momjian Exp $
+
+Parser
+------
+
 This directory does more than tokenize and parse SQL queries.  It also
 creates Query structures for the various complex queries that are passed
 to the optimizer and then executor.

src/backend/port/darwin/README

@@ -1,3 +1,8 @@
+$PostgreSQL: pgsql/src/backend/port/darwin/README,v 1.4 2008/03/20 17:55:14 momjian Exp $
+
+Darwin
+------
+
 The file system.c included herein is taken directly from Apple's Darwin
 open-source CVS archives, and is redistributed under the BSD copyright
 notice it bears.  (According to Apple's CVS logs, their version is

src/backend/snowball/README

@@ -1,4 +1,6 @@
-Snowball-based stemming
+$PostgreSQL: pgsql/src/backend/snowball/README,v 1.2 2008/03/20 17:55:14 momjian Exp $
+
+Snowball-Based Stemming
 -----------------------
 
 This module uses the word stemming code developed by the Snowball project,

src/backend/storage/buffer/README

@@ -1,6 +1,6 @@
-$PostgreSQL: pgsql/src/backend/storage/buffer/README,v 1.12 2007/05/30 20:11:58 tgl Exp $
+$PostgreSQL: pgsql/src/backend/storage/buffer/README,v 1.13 2008/03/20 17:55:15 momjian Exp $
 
-Notes about shared buffer access rules
+Notes About Shared Buffer Access Rules
 --------------------------------------
 
 There are two separate access control mechanisms for shared disk buffers:
@@ -92,7 +92,7 @@ for VACUUM's use, since we don't allow multiple VACUUMs concurrently on a
 single relation anyway.
 
 
-Buffer manager's internal locking
+Buffer Manager's Internal Locking
 ---------------------------------
 
 Before PostgreSQL 8.1, all operations of the shared buffer manager itself
@@ -152,7 +152,7 @@ we could use per-backend LWLocks instead (a buffer header would then contain
 a field to show which backend is doing its I/O).
 
 
-Normal buffer replacement strategy
+Normal Buffer Replacement Strategy
 ----------------------------------
 
 There is a "free list" of buffers that are prime candidates for replacement.
@@ -201,7 +201,7 @@ have to give up and try another buffer.  This however is not a concern
 of the basic select-a-victim-buffer algorithm.)
 
 
-Buffer ring replacement strategy
+Buffer Ring Replacement Strategy
 ---------------------------------
 
 When running a query that needs to access a large number of pages just once,
@@ -236,7 +236,7 @@ buffer, resulting in excessive WAL flushing.  Allowing VACUUM to update
 256KB between WAL flushes should be more efficient.
 
 
-Background writer's processing
+Background Writer's Processing
 ------------------------------
 
 The background writer is designed to write out pages that are likely to be