OSDN Git Service

(root) / pg-rex / syncrep.git / commitdiff
? search:
summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: e6557e9)
Attached patch cleans up the HTML code in tools/backend. This is
authorBruce Momjian <bruce@momjian.us>
Wed, 6 Apr 2005 15:19:03 +0000 (15:19 +0000)
committerBruce Momjian <bruce@momjian.us>
Wed, 6 Apr 2005 15:19:03 +0000 (15:19 +0000)
required for us to pull it into the main website. Same kind of fixes as
last time, just make sure things aren't violating the HTML standard. No
context changes at all.

Magnus Hagander

src/tools/backend/backend_dirs.html patch | blob | history
src/tools/backend/index.html patch | blob | history

diff --git a/src/tools/backend/backend_dirs.html b/src/tools/backend/backend_dirs.html
index cc4e16d..433324b 100644 (file)
--- a/src/tools/backend/backend_dirs.html
+++ b/src/tools/backend/backend_dirs.html
@@ -3,18 +3,17 @@
 <TITLE>PostgreSQL Backend Directories</TITLE>
 </HEAD>
 <BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#FF0000" VLINK="#A00000" ALINK="#0000FF">
-<H1 ALIGN=CENTER>
+<H1>
 PostgreSQL Backend Directories
 </H1>
-<H2 ALIGN=CENTER>
+<H2>
 by Bruce Momjian
 </H2>
-<P>
-<P>
 <HR>
+<P>
 <EM>Click on any of the section headings to see the source code for that section.
 </EM>
-<P>
+</P>
 <H2>
 <A NAME="bootstrap"></A>
 <A HREF="../../backend/bootstrap">bootstrap</A>
@@ -94,7 +93,7 @@ This uses the parser output to generate an optimal plan for the
 executor.
 </P>
 <H3>
-<A NAME="optimizer/path"></A>
+<A NAME="optimizer_path"></A>
 <A HREF="../../backend/optimizer/path">optimizer/path</A>
 - creates path from parser output
 </H3>
@@ -106,7 +105,7 @@ and optimizer table statistics to evaluate each possible execution
 method, and assigns a cost to each.
 </P>
 <H3>
-<A NAME="optimizer/geqo"></A>
+<A NAME="optimizer_geqo"></A>
 <A HREF="../../backend/optimizer/geqo">optimizer/geqo</A>
 - genetic query optimizer
 </H3>
@@ -121,7 +120,7 @@ tables, it is faster.
 There is an option to control when this feature is used.
 </P>
 <H3>
-<A NAME="optimizer/plan"></A>
+<A NAME="optimizer_plan"></A>
 <A HREF="../../backend/optimizer/plan">optimizer/plan</A>
 - optimizes path output
 </H3>
@@ -130,7 +129,7 @@ This takes the <I>optimizer/path</I> output, chooses the path with the
 least cost, and creates a plan for the executor.
 </P>
 <H3>
-<A NAME="optimizer/prep"></A>
+<A NAME="optimizer_prep"></A>
 <A HREF="../../backend/optimizer/prep">optimizer/prep</A>
 - handle special plan cases
 </H3>
@@ -138,7 +137,7 @@ least cost, and creates a plan for the executor.
 This does special plan processing.
 </P>
 <H3>
-<A NAME="optimizer/util"></A>
+<A NAME="optimizer_util"></A>
 <A HREF="../../backend/optimizer/util">optimizer/util</A>
 - optimizer support routines
 </H3>
@@ -190,31 +189,31 @@ that pre-format user requests into a predefined format.
 These allow uniform resource access by the backend.
 <BR>
 <BR>
-<A NAME="storage/buffer"></A>
+<A NAME="storage_buffer"></A>
 <A HREF="../../backend/storage/buffer">storage/buffer</A>
 - shared buffer pool manager
 <BR>
-<A NAME="storage/file"></A>
+<A NAME="storage_file"></A>
 <A HREF="../../backend/storage/file">storage/file</A>
 - file manager
 <BR>
-<A NAME="storage/ipc"></A>
+<A NAME="storage_ipc"></A>
 <A HREF="../../backend/storage/ipc">storage/ipc</A>
 - semaphores and shared memory
 <BR>
-<A NAME="storage/large_object"></A>
+<A NAME="storage_large_object"></A>
 <A HREF="../../backend/storage/large_object">storage/large_object</A>
 - large objects
 <BR>
-<A NAME="storage/lmgr"></A>
+<A NAME="storage_lmgr"></A>
 <A HREF="../../backend/storage/lmgr">storage/lmgr</A>
 - lock manager
 <BR>
-<A NAME="storage/page"></A>
+<A NAME="storage_page"></A>
 <A HREF="../../backend/storage/page">storage/page</A>
 - page manager
 <BR>
-<A NAME="storage/smgr"></A>
+<A NAME="storage_smgr"></A>
 <A HREF="../../backend/storage/smgr">storage/smgr</A>
 - storage/disk manager
 <BR>
@@ -230,35 +229,35 @@ These control the way data is accessed in heap, indexes, and
 transactions.
 <BR>
 <BR>
-<A NAME="access/common"></A>
+<A NAME="access_common"></A>
 <A HREF="../../backend/access/common">access/common</A>
 - common access routines
 <BR>
-<A NAME="access/gist"></A>
+<A NAME="access_gist"></A>
 <A HREF="../../backend/access/gist">access/gist</A>
 - easy-to-define access method system
 <BR>
-<A NAME="access/hash"></A>
+<A NAME="access_hash"></A>
 <A HREF="../../backend/access/hash">access/hash</A>
 - hash
 <BR>
-<A NAME="access/heap"></A>
+<A NAME="access_heap"></A>
 <A HREF="../../backend/access/heap">access/heap</A>
 - heap is use to store data rows
 <BR>
-<A NAME="access/index"></A>
+<A NAME="access_index"></A>
 <A HREF="../../backend/access/index">access/index</A>
 - used by all index types
 <BR>
-<A NAME="access/nbtree"></A>
+<A NAME="access_nbtree"></A>
 <A HREF="../../backend/access/nbtree">access/nbtree</A>
 - Lehman and Yao's btree management algorithm 
 <BR>
-<A NAME="access/rtree"></A>
+<A NAME="access_rtree"></A>
 <A HREF="../../backend/access/rtree">access/rtree</A>
 - used for indexing of 2-dimensional data
 <BR>
-<A NAME="access/transam"></A>
+<A NAME="access_transam"></A>
 <A HREF="../../backend/access/transam">access/transam</A>
 - transaction manager (BEGIN/ABORT/COMMIT)
 <BR>
@@ -289,7 +288,7 @@ store requests and data.
 - support routines
 </H2>
 <H3>
-<A NAME="utils/adt"></A>
+<A NAME="utils_adt"></A>
 <A HREF="../../backend/utils/adt">utils/adt</A>
 - built-in data type routines
 </H3>
@@ -297,7 +296,7 @@ store requests and data.
 This contains all the PostgreSQL builtin data types.
 </P>
 <H3>
-<A NAME="utils/cache"></A>
+<A NAME="utils_cache"></A>
 <A HREF="../../backend/utils/cache">utils/cache</A>
 - system/relation/function cache routines
 </H3>
@@ -314,7 +313,7 @@ This last cache maintains information about all recently-accessed
 tables, not just system ones.
 </P>
 <H3>
-<A NAME="utils/error"></A>
+<A NAME="utils_error"></A>
 <A HREF="../../backend/utils/error">utils/error</A>
 - error reporting routines
 </H3>
@@ -322,7 +321,7 @@ tables, not just system ones.
 Reports backend errors to the front end.
 </P>
 <H3>
-<A NAME="utils/fmgr"></A>
+<A NAME="utils_fmgr"></A>
 <A HREF="../../backend/utils/fmgr">utils/fmgr</A>
 - function manager
 </H3>
@@ -331,7 +330,7 @@ This handles the calling of dynamically-loaded functions, and the calling
 of functions defined in the system tables.
 </P>
 <H3>
-<A NAME="utils/hash"></A>
+<A NAME="utils_hash"></A>
 <A HREF="../../backend/utils/hash">utils/hash</A>
 - hash routines for internal algorithms
 </H3>
@@ -341,17 +340,17 @@ do quick lookups of dynamic data storage structures maintained by the
 backend.
 </P>
 <H3>
-<A NAME="utils/init"></A>
+<A NAME="utils_init"></A>
 <A HREF="../../backend/utils/init">utils/init</A>
 - various initialization stuff
 </H3>
 <H3>
-<A NAME="utils/misc"></A>
+<A NAME="utils_misc"></A>
 <A HREF="../../backend/utils/misc">utils/misc</A>
 - miscellaneous stuff
 </H3>
 <H3>
-<A NAME="utils/mmgr"></A>
+<A NAME="utils_mmgr"></A>
 <A HREF="../../backend/utils/mmgr">utils/mmgr</A>
 - memory manager(process-local memory)
 </H3>
@@ -363,7 +362,7 @@ By doing this, the backend can easily free memory once a statement or
 transaction completes.
 </P>
 <H3>
-<A NAME="utils/sort"></A>
+<A NAME="utils_sort"></A>
 <A HREF="../../backend/utils/sort">utils/sort</A>
 - sort routines for internal algorithms
 </H3>
@@ -372,7 +371,7 @@ When statement output must be sorted as part of a backend operation,
 this code sorts the tuples, either in memory or using disk files.
 </P>
 <H3>
-<A NAME="utils/time"></A>
+<A NAME="utils_time"></A>
 <A HREF="../../backend/utils/time">utils/time</A>
 - transaction time qualification routines
 </H3>
@@ -419,13 +418,11 @@ This does processing for the rules system.
 - unused (array handling?)
 </H2>
 <BR>
-<HR SIZE="2" NOSHADE>
+<HR>
 <SMALL>
-<ADDRESS>
 Maintainer:    Bruce Momjian (<A
 HREF="mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
 Last updated:          Tue Dec  9 17:56:08 EST 1997
-</ADDRESS>
 </SMALL>
 </BODY>
 </HTML>
diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html
index 78b8b8e..241c4bb 100644 (file)
--- a/src/tools/backend/index.html
+++ b/src/tools/backend/index.html
@@ -3,42 +3,40 @@
 <TITLE>How PostgreSQL Processes a Query</TITLE>
 </HEAD>
 <BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#FF0000" VLINK="#A00000" ALINK="#0000FF">
-<H1 ALIGN=CENTER>
+<H1>
 How PostgreSQL Processes a Query
 </H1>
-<H2 ALIGN=CENTER>
+<H2>
 by Bruce Momjian
 </H2>
 <P>
-<CENTER>
-<IMG src="flow.gif" usemap="#flowmap" alt="flowchart" border=0>
-</CENTER>
-<MAP name="flowmap">
-<AREA COORDS="125,35,245,65" HREF="backend_dirs.html#main">
-<AREA COORDS="125,100,245,125" HREF="backend_dirs.html#postmaster">
-<AREA COORDS="325,65,450,95" HREF="backend_dirs.html#libpq">
-<AREA COORDS="125,160,245,190" HREF="backend_dirs.html#tcop">
-<AREA COORDS="325,160,450,190" HREF="backend_dirs.html#tcop">
-<AREA COORDS="125,240,245,265" HREF="backend_dirs.html#parser">
-<AREA COORDS="125,300,250,330" HREF="backend_dirs.html#tcop">
-<AREA COORDS="125,360,250,390" HREF="backend_dirs.html#optimizer">
-<AREA COORDS="125,425,245,455" HREF="backend_dirs.html#optimizer/plan">
-<AREA COORDS="125,490,245,515" HREF="backend_dirs.html#executor">
-<AREA COORDS="325,300,450,330" HREF="backend_dirs.html#commands">
-<AREA COORDS="75,575,195,605" HREF="backend_dirs.html#utils">
-<AREA COORDS="235,575,360,605" HREF="backend_dirs.html#catalog">
-<AREA COORDS="405,575,525,605" HREF="backend_dirs.html#storage">
-<AREA COORDS="155,635,275,665" HREF="backend_dirs.html#access">
-<AREA COORDS="325,635,450,665" HREF="backend_dirs.html#nodes">
-<AREA COORDS="75,705,200,730" HREF="backend_dirs.html#bootstrap">
+<IMG src="flow.gif" usemap="#flowmap" alt="flowchart">
+<MAP name="flowmap" id="flowmap">
+<AREA coords="125,35,245,65" HREF="backend_dirs.html#main" alt="main"></AREA>
+<AREA coords="125,100,245,125" HREF="backend_dirs.html#postmaster" alt="postmaster"></AREA>
+<AREA coords="325,65,450,95" HREF="backend_dirs.html#libpq" alt="libpq"></AREA>
+<AREA coords="125,160,245,190" HREF="backend_dirs.html#tcop" alt="tcop"></AREA>
+<AREA coords="325,160,450,190" HREF="backend_dirs.html#tcop" alt="tcop"></AREA>
+<AREA coords="125,240,245,265" HREF="backend_dirs.html#parser" alt="parser"></AREA>
+<AREA coords="125,300,250,330" HREF="backend_dirs.html#tcop" alt="tcop"></AREA>
+<AREA coords="125,360,250,390" HREF="backend_dirs.html#optimizer" alt="optimizer"></AREA>
+<AREA coords="125,425,245,455" HREF="backend_dirs.html#optimizer_plan" alt="plan"></AREA>
+<AREA coords="125,490,245,515" HREF="backend_dirs.html#executor" alt="executor"></AREA>
+<AREA coords="325,300,450,330" HREF="backend_dirs.html#commands" alt="commands"></AREA>
+<AREA coords="75,575,195,605" HREF="backend_dirs.html#utils" alt="utils"></AREA>
+<AREA coords="235,575,360,605" HREF="backend_dirs.html#catalog" alt="catalog"></AREA>
+<AREA coords="405,575,525,605" HREF="backend_dirs.html#storage" alt="storage"></AREA>
+<AREA coords="155,635,275,665" HREF="backend_dirs.html#access" alt="access"></AREA>
+<AREA coords="325,635,450,665" HREF="backend_dirs.html#nodes" alt="nodes"></AREA>
+<AREA coords="75,705,200,730" HREF="backend_dirs.html#bootstrap" alt="bootstrap"></AREA>
 </MAP>
-<CENTER><EM>
+<EM>
 Click on an item to see more detail or look at the full
 <A HREF="backend_dirs.html">index.</A>
-</EM></CENTER>
+</EM>
 <BR>
 <BR>
-
+</P>
 <P>
 
 A query comes to the backend via data packets arriving through TCP/IP or
@@ -49,13 +47,13 @@ into tokens(words).  The parser uses <A
 HREF="../../backend/parser/gram.y">gram.y</A> and the tokens to identify
 the query type, and load the proper query-specific structure, like <A
 HREF="../../include/nodes/parsenodes.h">CreateStmt</A> or <A
-HREF="../../include/nodes/parsenodes.h">SelectStmt.</A><P>
+HREF="../../include/nodes/parsenodes.h">SelectStmt.</A></P><P>
 
 
 The query is then identified as a <I>Utility</I> query or a more complex
 query.  A <I>Utility</I> query is processed by a query-specific function
 in <A HREF="../../backend/commands"> commands.</A> A complex query, like
-<I>SELECT, UPDATE,</I> and <I>DELETE</I> requires much more handling.<P>
+<I>SELECT, UPDATE,</I> and <I>DELETE</I> requires much more handling.</P><P>
 
 
 The parser takes a complex query, and creates a
@@ -67,7 +65,7 @@ Each table referenced in the query is represented by a <A
 HREF="../../include/nodes/parsenodes.h"> RangeTableEntry,</A> and they
 are linked together to form the <I>range table</I> of the query, which
 is generated by <A HREF="../../backend/parser/parse_clause.c">
-transformFromClause().</A>  Query.rtable holds the query's range table.<P>
+transformFromClause().</A>  Query.rtable holds the query's range table.</P><P>
 
 
 Certain queries, like <I>SELECT,</I> return columns of data.  Other
@@ -78,16 +76,16 @@ placed in <A HREF="../../include/nodes/parsenodes.h">target list
 entries,</A> and linked together to make up the <I>target list</I> of
 the query. The target list is stored in Query.targetList, which is
 generated by <A
-HREF="../../backend/parser/parse_target.c">transformTargetList().</A><P>
+HREF="../../backend/parser/parse_target.c">transformTargetList().</A></P><P>
 
 
 Other query elements, like aggregates(<I>SUM()</I>), <I>GROUP BY,</I>
-and <I>ORDER BY</I> are also stored in their own Query fields.<P>
+and <I>ORDER BY</I> are also stored in their own Query fields.</P><P>
 
 
 The next step is for the Query to be modified by any <I>VIEWS</I> or
 <I>RULES</I> that may apply to the query.  This is performed by the <A
-HREF="../../backend/rewrite">rewrite</A> system.<P>
+HREF="../../backend/rewrite">rewrite</A> system.</P><P>
 
 
 The <A HREF="../../backend/optimizer">optimizer</A> takes the Query
@@ -96,18 +94,17 @@ HREF="../../include/nodes/plannodes.h">Plan,</A> which contains the
 operations to be performed to execute the query.  The <A
 HREF="../../backend/optimizer/path">path</A> module determines the best
 table join order and join type of each table in the RangeTable, using
-Query.qual(<I>WHERE</I> clause) to consider optimal index usage.<P>
+Query.qual(<I>WHERE</I> clause) to consider optimal index usage.</P><P>
 
 
 The Plan is then passed to the <A
 HREF="../../backend/executor">executor</A> for execution, and the result
 returned to the client.  The Plan actually as set of nodes, arranged in
 a tree structure with a top-level node, and various sub-nodes as
-children.<P>
-
+children.</P><P>
 
 There are many other modules that support this basic functionality. They
-can be accessed by clicking on the flowchart.<P>
+can be accessed by clicking on the flowchart.</P>
 
 
 <HR><P>
@@ -117,19 +114,20 @@ Another area of interest is the shared memory area, which contains data
 accessable to all backends.  It has recently used data/index blocks,
 locks, backend process information, and lookup tables for these
 structures:
+</P>
 
 <UL> 
-<LI>ShmemIndex - lookup shared memory addresses using structure names
+<LI>ShmemIndex - lookup shared memory addresses using structure names</LI>
 <LI><A HREF="../../include/storage/buf_internals.h">Buffer
-Descriptor</A> - control header for buffer cache block
+Descriptor</A> - control header for buffer cache block</LI>
 <LI><A HREF="../../include/storage/buf_internals.h">Buffer Block</A> -
-data/index buffer cache block
+data/index buffer cache block</LI>
 <LI>Shared Buffer Lookup Table - lookup of buffer cache block addresses
 using table name and block number(<A
-HREF="../../include/storage/buf_internals.h"> BufferTag</A>)
+HREF="../../include/storage/buf_internals.h"> BufferTag</A>)</LI>
 <LI>MultiLevelLockTable (ctl) - control structure for each locking
 method.  Currently, only multi-level locking is used(<A
-HREF="../../include/storage/lock.h">LOCKMETHODCTL</A>).
+HREF="../../include/storage/lock.h">LOCKMETHODCTL</A>).</LI>
 <LI>MultiLevelLockTable (lock hash) - the <A
 HREF="../../include/storage/lock.h">LOCK</A> structure, looked up using
 relation, database object ids(<A
@@ -137,31 +135,29 @@ HREF="../../include/storage/lock.h">LOCKTAG)</A>.  The lock table
 structure contains the lock modes(read/write or shared/exclusive) and
 circular linked list of backends (<A
 HREF="../../include/storage/proc.h">PROC</A> structure pointers) waiting
-on the lock.
+on the lock.</LI>
 <LI>MultiLevelLockTable (xid hash) - lookup of LOCK structure address
 using transaction id, LOCK address.  It is used to quickly check if the
 current transaction already has any locks on a table, rather than having
 to search through all the held locks.  It also stores the modes
 (read/write) of the locks held by the current transaction.  The returned
 <A HREF="../../include/storage/lock.h">XIDLookupEnt</A> structure also
-contains a pointer to the backend's PROC.lockQueue.
+contains a pointer to the backend's PROC.lockQueue.</LI>
 <LI><A HREF="../../include/storage/proc.h">Proc Header</A> - information
-about each backend, including locks held/waiting, indexed by process id
+about each backend, including locks held/waiting, indexed by process id</LI>
 </UL>
 
-Each data structure is created by calling <A
+<P>Each data structure is created by calling <A
 HREF="../../backend/storage/ipc/shmem.c">ShmemInitStruct(),</A> and the
 lookups are created by <A
-HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().</A><P>
+HREF="../../backend/storage/ipc/shmem.c">ShmemInitHash().</A></P>
 
 
-<HR SIZE="2" NOSHADE>
+<HR>
 <SMALL>
-<ADDRESS>
 Maintainer:    Bruce Momjian (<A
 HREF="mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
 Last updated:          Mon Aug 10 10:48:06 EDT 1998
-</ADDRESS>
 </SMALL>
 </BODY>
 </HTML>
PostgreSQL9.0用の同期レプリケーションパッチ
About OSDN
Find Software
Develop Software
Help