Remove src/tool/backend, now that the content is on the web site and wiki.
authorBruce Momjian
Tue, 4 Sep 2012 16:38:33 +0000 (12:38 -0400)
committerBruce Momjian
Tue, 4 Sep 2012 16:38:33 +0000 (12:38 -0400)
src/tools/backend/README [deleted file]
src/tools/backend/backend_dirs.html [deleted file]
src/tools/backend/flow.fig [deleted file]
src/tools/backend/flow.gif [deleted file]
src/tools/backend/index.html [deleted file]

diff --git a/src/tools/backend/README b/src/tools/backend/README
deleted file mode 100644 (file)
index 2b8692d..0000000
+++ /dev/null
@@ -1,4 +0,0 @@
-src/tools/backend/README
-
-Just point your browser at the index.html file, and click on the
-flowchart to see the description and source code.
diff --git a/src/tools/backend/backend_dirs.html b/src/tools/backend/backend_dirs.html
deleted file mode 100644 (file)
index 16bd894..0000000
+++ /dev/null
@@ -1,349 +0,0 @@
-
-    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-
-
-content="HTML Tidy for BSD/OS (vers 1st July 2002), see www.w3.org" />
-PostgreSQL Backend Directories
-
-
-vlink="#A00000" alink="#0000FF">
-

PostgreSQL Backend Directories

-
-

by Bruce Momjian

-
-
-

Click on any of the section headings to see the source code

-for that section.

-
-

 
-href="../../backend/bootstrap">bootstrap - creates initial
-template database via initdb

-
-

Because PostgreSQL requires access to system tables for almost

-every operation, getting those system tables in place is a problem.
-You can't just create the tables and insert data into them in the
-normal way, because table creation and insertion requires the
-tables to already exist. This code jams the data directly
-into tables using a special syntax used only by the bootstrap
-procedure.

-
-

 
-href="../../backend/main">main - passes control to postmaster
-or postgres

-
-

This checks the process name(argv[0]) and various flags, and

-passes control to the postmaster or postgres backend code.

-
-

 
-href="../../backend/postmaster">postmaster - controls postgres
-server startup/termination

-
-

This creates shared memory, and then goes into a loop waiting

-for connection requests. When a connection request arrives, a
-postgres backend is started, and the connection is passed to
-it.

-
-

 
-href="../../backend/libpq">libpq - backend libpq library
-routines

-
-

This handles communication to the client processes.

-
-

 
-href="../../backend/tcop">tcop - traffic cop, dispatches
-request to proper module

-
-

This contains the postgres backend main handler, as well

-as the code that makes calls to the parser, optimizer, executor,
-and /commands functions.

-
-

 
-href="../../backend/parser">parser - converts SQL query to
-query tree

-
-

This converts SQL queries coming from libpq into

-command-specific structures to be used the optimizer/executor,
-or /commands routines. The SQL is lexically analyzed into
-keywords, identifiers, and constants, and passed to the parser. The
-parser creates command-specific structures to hold the elements of
-the query. The command-specific structures are then broken apart,
-checked, and passed to /commands processing routines, or
-converted into Lists of Nodes to be handled by the
-optimizer and executor.

-
-

 
-href="../../backend/rewrite">rewrite - rule and views
-support

-
-

 
-href="../../backend/optimizer">optimizer - creates path and
-plan

-
-

This uses the parser output to generate an optimal plan for the

-executor.

-
-

 
-href="../../backend/optimizer/path">optimizer/path - creates
-path from parser output

-
-

This takes the parser query output, and generates all possible

-methods of executing the request. It examines table join order,
-where clause restrictions, and optimizer table statistics to
-evaluate each possible execution method, and assigns a cost to
-each.

-
-

 
-href="../../backend/optimizer/geqo">optimizer/geqo - genetic
-query optimizer

-
-

optimizer/path evaluates all possible ways to join the

-requested tables. When the number of tables becomes great, the
-number of tests made becomes great too. The Genetic Query Optimizer
-considers each table separately, then figures the most optimal
-order to perform the join. For a few tables, this method takes
-longer, but for a large number of tables, it is faster. There is an
-option to control when this feature is used.

-
-

 
-href="../../backend/optimizer/plan">optimizer/plan - optimizes
-path output

-
-

This takes the optimizer/path output, chooses the path

-with the least cost, and creates a plan for the executor.

-
-

 
-href="../../backend/optimizer/prep">optimizer/prep - handle
-special plan cases

-
-

This does special plan processing.

-
-

 
-href="../../backend/optimizer/util">optimizer/util - optimizer
-support routines

-
-

This contains support routines used by other parts of the

-optimizer.

-
-

 
-href="../../backend/executor">executor - executes complex node
-plans from optimizer

-
-

This handles select, insert, update, and delete

-statements. The operations required to handle these statement types
-include heap scans, index scans, sorting, joining tables, grouping,
-aggregates, and uniqueness.

-
-

 
-href="../../backend/commands">commands - commands that do not
-require the executor

-
-

These process SQL commands that do not require complex handling.

-It includes vacuum, copy, alter, create table, create type,
-and many others. The code is called with the structures generated
-by the parser. Most of the routines do some processing, then call
-lower-level functions in the catalog directory to do the actual
-work.

-
-

 
-href="../../backend/catalog">catalog - system catalog
-manipulation

-
-

This contains functions that manipulate the system tables or

-catalogs. Table, index, procedure, operator, type, and aggregate
-creation and manipulation routines are here. These are low-level
-routines, and are usually called by upper routines that pre-format
-user requests into a predefined format.

-
-

 
-href="../../backend/storage">storage - manages various storage
-systems

-
-

These allow uniform resource access by the backend.

-
 
-href="../../backend/storage/buffer">storage/buffer - shared
-buffer pool manager
 
-href="../../backend/storage/file">storage/file - file
-manager
 
-href="../../backend/storage/freespace">storage/freespace - free
-space map
 
-href="../../backend/storage/ipc">storage/ipc - semaphores and
-shared memory
 
-href="../../backend/storage/large_object">storage/large_object
-- large objects
 
-href="../../backend/storage/lmgr">storage/lmgr - lock
-manager
 
-href="../../backend/storage/page">storage/page - page
-manager
 
-href="../../backend/storage/smgr">storage/smgr - storage/disk
-manager
-
-

-
-

 
-href="../../backend/access">access - various data access
-methods

-
-

These control the way data is accessed in heap, indexes, and

-transactions.
-
 
-href="../../backend/access/common">access/common - common
-access routines
 
-href="../../backend/access/gist">access/gist - easy-to-define
-access method system
 
-href="../../backend/access/hash">access/hash - hash
 
-href="../../backend/access/heap">access/heap - heap is use to
-store data rows
 
-href="../../backend/access/index">access/index - used by all
-index types
 
-href="../../backend/access/nbtree">access/nbtree - Lehman and
-Yao's btree management algorithm
 
-href="../../backend/access/transam">access/transam -
-transaction manager (BEGIN/ABORT/COMMIT)
-
-

-
-

 
-href="../../backend/nodes">nodes - creation/manipulation of
-nodes and lists

-
-

PostgreSQL stores information about SQL queries in structures

-called nodes. Nodes are generic containers that have a
-type field and then a type-specific data section. Nodes are
-usually placed in Lists. A List is container with an
-elem element, and a next field that points to the
-next List. These List structures are chained together
-in a forward linked list. In this way, a chain of List s can
-contain an unlimited number of Node elements, and each
-Node can contain any data type. These are used extensively
-in the parser, optimizer, and executor to store requests and
-data.

-
-

 
-href="../../backend/utils">utils - support routines

-
-

 
-href="../../backend/utils/adt">utils/adt - built-in data type
-routines

-
-

This contains all the PostgreSQL builtin data types.

-
-

 
-href="../../backend/utils/cache">utils/cache -
-system/relation/function cache routines

-
-

PostgreSQL supports arbitrary data types, so no data types are

-hard-coded into the core backend routines. When the backend needs
-to find out about a type, is does a lookup of a system table.
-Because these system tables are referred to often, a cache is
-maintained that speeds lookups. There is a system relation cache, a
-function/operator cache, and a relation information cache. This
-last cache maintains information about all recently-accessed
-tables, not just system ones.

-
-

 
-href="../../backend/utils/error">utils/error - error reporting
-routines

-
-

Reports backend errors to the front end.

-
-

 
-href="../../backend/utils/fmgr">utils/fmgr - function
-manager

-
-

This handles the calling of dynamically-loaded functions, and

-the calling of functions defined in the system tables.

-
-

 
-href="../../backend/utils/hash">utils/hash - hash routines for
-internal algorithms

-
-

These hash routines are used by the cache and memory-manager

-routines to do quick lookups of dynamic data storage structures
-maintained by the backend.

-
-

 
-href="../../backend/utils/init">utils/init - various
-initialization stuff

-
-

 
-href="../../backend/utils/mb">utils/mb - single and multibyte
-encoding

-
-

 
-href="../../backend/utils/misc">utils/misc - miscellaneous
-stuff

-
-

 
-href="../../backend/utils/mmgr">utils/mmgr - memory
-manager(process-local memory)

-
-

When PostgreSQL allocates memory, it does so in an explicit

-context. Contexts can be statement-specific, transaction-specific,
-or persistent/global. By doing this, the backend can easily free
-memory once a statement or transaction completes.

-
-

 
-href="../../backend/utils/resowner">utils/resowner - resource
-owner tracking

-
-

 
-href="../../backend/utils/sort">utils/sort - sort routines for
-internal algorithms

-
-

When statement output must be sorted as part of a backend

-operation, this code sorts the tuples, either in memory or using
-disk files.

-
-

 
-href="../../backend/utils/time">utils/time - transaction time
-qualification routines

-
-

These routines do checking of tuple internal columns to

-determine if the current row is still valid, or is part of a
-non-committed transaction or superseded by a new row.

-
-

 
-href="../../backend/include">include - include files

-
-

There are include directories for each subsystem.

-
-

 lib

-- support library
-
-

This houses several generic routines.

-
-

 
-href="../../backend/regex">regex - regular expression
-library

-
-

This is used for regular expression handling in the backend,

-i.e. '~'.

-
-

 
-href="../../backend/port">port - compatibility routines

-
-
-
-
-Maintainer: Bruce Momjian ( 
-)
- Last updated: Fri May 6 14:22:27 EDT 2005
-
-
diff --git a/src/tools/backend/flow.fig b/src/tools/backend/flow.fig
deleted file mode 100644 (file)
index b10aa2c..0000000
+++ /dev/null
@@ -1,143 +0,0 @@
-#FIG 3.2  Produced by xfig version 3.2.5
-Portrait
-Center
-Inches
-Letter  
-88.00
-Single
--2
-1200 2
-0 32 #919191
-0 33 #c5ddc1
-2 4 0 1 -1 26 1 0 20 0.000 0 0 7 0 0 5
-    3600 900 1200 900 1200 300 3600 300 3600 900
-2 4 0 1 -1 4 1 0 20 0.000 0 0 7 0 0 5
-    3600 2100 1200 2100 1200 1500 3600 1500 3600 2100
-2 4 0 1 -1 0 1 0 20 0.000 0 0 7 0 0 5
-    7500 1500 5100 1500 5100 900 7500 900 7500 1500
-2 4 0 1 -1 31 1 0 20 0.000 0 0 7 0 0 5
-    3600 3300 1200 3300 1200 2700 3600 2700 3600 3300
-2 4 0 1 -1 8 1 0 20 0.000 0 0 7 0 0 5
-    3600 6000 1200 6000 1200 5400 3600 5400 3600 6000
-2 4 0 1 -1 31 1 0 20 0.000 0 0 7 0 0 5
-    7500 3300 5100 3300 5100 2700 7500 2700 7500 3300
-2 4 0 1 -1 8 1 0 20 0.000 0 0 7 0 0 5
-    3600 8400 1200 8400 1200 7800 3600 7800 3600 8400
-2 4 0 1 -1 8 1 0 20 0.000 0 0 7 0 0 5
-    3600 9600 1200 9600 1200 9000 3600 9000 3600 9600
-2 1 2 2 -1 7 0 0 -1 3.000 0 1 -1 1 1 2
-   0 0 2.00 80.00 150.00
-   0 0 2.00 80.00 150.00
-    4500 1425 5135 1194
-2 1 2 2 -1 7 0 0 -1 4.000 0 1 -1 1 1 2
-   0 0 2.00 80.00 150.00
-   0 0 2.00 80.00 150.00
-    4725 2025 5160 1467
-2 1 0 2 20 7 1 0 -1 0.000 0 0 -1 1 0 2
-   0 0 2.00 150.00 180.00
-    2400 2100 2400 2700
-2 1 0 2 31 7 1 0 -1 0.000 0 0 -1 1 0 2
-   0 0 2.00 150.00 180.00
-    2400 3300 2400 4275
-2 4 0 1 -1 8 1 0 20 0.000 0 0 7 0 0 5
-    3600 7200 1200 7200 1200 6600 3600 6600 3600 7200
-2 4 0 1 -1 8 1 0 20 0.000 0 0 7 0 0 5
-    3600 10800 1200 10800 1200 10200 3600 10200 3600 10800
-2 4 0 1 -1 8 1 0 20 0.000 0 0 7 0 0 5
-    3600 4800 1200 4800 1200 4200 3600 4200 3600 4800
-2 1 1 2 32 7 1 0 -1 4.000 0 0 -1 1 0 2
-   0 0 2.00 150.00 180.00
-    2400 8400 2400 9000
-2 1 1 2 32 7 1 0 -1 4.000 0 0 -1 1 0 2
-   0 0 2.00 150.00 180.00
-    2400 7200 2400 7800
-2 1 1 2 32 7 1 0 -1 4.000 0 0 -1 1 0 2
-   0 0 2.00 150.00 180.00
-    2400 6000 2400 6600
-2 1 1 2 32 7 1 0 -1 4.000 0 0 -1 1 0 2
-   0 0 2.00 150.00 180.00
-    2400 4800 2400 5400
-2 1 1 2 32 7 1 0 -1 4.000 0 0 -1 1 0 2
-   0 0 2.00 150.00 180.00
-    3600 5700 5100 5700
-2 1 0 2 25 7 0 0 -1 0.000 0 0 -1 1 0 2
-   0 0 2.00 150.00 180.50
-    2400 900 2400 1500
-2 4 0 1 -1 8 1 0 20 0.000 0 0 7 0 0 5
-    7500 6000 5100 6000 5100 5400 7500 5400 7500 6000
-2 4 0 1 33 33 3 0 20 0.000 0 0 40 0 0 5
-    8700 11100 300 11100 300 3600 8700 3600 8700 11100
-2 1 0 2 29 7 0 0 -1 0.000 0 0 -1 1 1 2
-   0 0 2.00 150.00 180.00
-   0 0 2.00 150.00 180.00
-    3150 13050 3150 13650
-2 1 0 2 29 7 0 0 -1 0.000 0 0 -1 1 1 2
-   0 0 2.00 150.00 180.00
-   0 0 2.00 150.00 180.00
-    1500 12450 1500 11850
-2 4 0 1 -1 29 1 0 20 0.000 0 0 7 0 0 5
-    2700 13050 300 13050 300 12450 2700 12450 2700 13050
-2 4 0 1 -1 29 1 0 20 0.000 0 0 7 0 0 5
-    6000 13050 3600 13050 3600 12450 6000 12450 6000 13050
-2 4 0 1 -1 29 1 0 20 0.000 0 0 7 0 0 5
-    7500 14250 5100 14250 5100 13650 7500 13650 7500 14250
-2 4 0 1 -1 29 1 0 20 0.000 0 0 7 0 0 5
-    4200 14250 1800 14250 1800 13650 4200 13650 4200 14250
-2 1 0 2 29 7 0 0 -1 0.000 0 0 -1 1 1 2
-   0 0 2.00 150.00 180.00
-   0 0 2.00 150.00 180.00
-    4800 12450 4800 11850
-2 1 0 2 29 7 0 0 -1 0.000 0 0 -1 1 1 2
-   0 0 2.00 150.00 180.00
-   0 0 2.00 150.00 180.00
-    6300 13050 6300 13650
-2 4 0 1 -1 29 1 0 20 0.000 0 0 7 0 0 5
-    9300 13050 6600 13050 6600 12450 9300 12450 9300 13050
-2 1 0 2 29 7 0 0 -1 0.000 0 0 -1 1 1 2
-   0 0 2.00 150.00 180.00
-   0 0 2.00 150.00 180.00
-    7950 11850 7950 12450
-2 1 1 2 5 7 1 0 -1 4.000 0 0 -1 1 0 2
-   0 0 2.00 150.00 180.00
-    2400 6000 2400 6600
-2 1 1 2 32 7 1 0 -1 4.000 0 0 -1 1 0 2
-   0 0 2.00 150.00 180.00
-    2400 9600 2400 10200
-3 2 2 2 20 7 0 0 -1 6.000 1 1 0 5
-   0 0 2.00 150.00 180.00
-    2415 2140 3090 2440 5265 2515 6090 2590 6315 2740
-    0.000 -1.000 -1.000 -1.000 0.000
-3 0 1 2 32 7 1 0 -1 4.500 0 1 0 7
-   0 0 2.00 150.00 150.00
-    7500 5700 8400 5400 8400 4500 7800 3900 3600 3900 3000 3900
-    2700 4200
-    0.000 1.000 1.000 1.000 1.000 1.000 0.000
-3 0 1 2 32 7 0 0 -1 4.000 0 1 0 8
-   0 0 2.00 150.00 150.00
-    1125 10500 900 10350 675 9975 675 4350 900 3975 1350 3900
-    1800 3900 2100 4200
-    0.000 1.000 1.000 1.000 1.000 1.000 1.000 0.000
-4 1 5 2 0 28 18 0.0000 4 285 870 4350 5625 utility\001
-4 1 -1 0 0 16 18 0.0000 4 210 1455 2400 1950 Postmaster\001
-4 1 -1 0 0 16 18 0.0000 4 270 1125 2400 3150 Postgres\001
-4 1 -1 0 0 16 18 0.0000 4 270 1125 6300 3150 Postgres\001
-4 1 7 0 0 16 18 0.0000 4 270 720 6300 1350 Libpq\001
-4 1 -1 0 0 16 18 0.0000 4 210 615 2400 750 Main\001
-4 1 7 0 0 16 18 0.0000 4 210 1815 2400 9450 Generate Plan\001
-4 1 7 0 0 16 18 0.0000 4 270 1440 2400 5850 Traffic Cop\001
-4 1 7 0 0 16 18 0.0000 4 210 1980 2400 8250 Generate Paths\001
-4 1 5 2 0 28 18 0.0000 4 225 615 2400 9900 Plan\001
-4 1 5 2 0 28 18 0.0000 4 285 1920 2400 8700 Optimal Path\001
-4 1 5 2 0 28 18 0.0000 4 285 900 2400 6300 Query\001
-4 1 7 0 0 16 18 0.0000 4 210 1680 2400 10650 Execute Plan\001
-4 0 5 0 0 16 12 0.0000 4 210 2640 5250 6300 e.g. CREATE TABLE, COPY\001
-4 1 5 0 0 16 12 0.0000 4 195 3540 2400 6525 SELECT, INSERT, UPDATE, DELETE\001
-4 1 7 0 0 16 18 0.0000 4 270 1800 2400 7050 Rewrite Query\001
-4 1 7 0 0 16 18 0.0000 4 210 2130 2400 4650 Parse Statement\001
-4 1 7 0 0 16 18 0.0000 4 270 720 6300 5700 Utility\001
-4 1 7 0 0 16 18 0.0000 4 210 1335 6300 6000 Command\001
-4 1 -1 0 0 16 18 0.0000 4 270 2355 7950 12900 Storage Managers\001
-4 1 -1 0 0 16 18 0.0000 4 270 1020 4800 12900 Catalog\001
-4 1 -1 0 0 16 18 0.0000 4 210 915 1500 12900 Utilities\001
-4 1 -1 0 0 16 18 0.0000 4 210 2085 3000 14100 Access Methods\001
-4 1 -1 0 0 16 18 0.0000 4 210 1635 6300 14100 Nodes / Lists\001
diff --git a/src/tools/backend/flow.gif b/src/tools/backend/flow.gif
deleted file mode 100644 (file)
index e0cd8db..0000000
Binary files a/src/tools/backend/flow.gif and /dev/null differ
diff --git a/src/tools/backend/index.html b/src/tools/backend/index.html
deleted file mode 100644 (file)
index eb4978b..0000000
+++ /dev/null
@@ -1,155 +0,0 @@
-
-
-    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
-
-
-content="HTML Tidy for BSD/OS (vers 1st July 2002), see www.w3.org" />
-How PostgreSQL Processes a Query
-
-
-vlink="#A00000" alink="#0000FF">
-

How PostgreSQL Processes a Query

-
-

by Bruce Momjian

-
-
-

Click on an item to see more detail or look at the full

-index.
-
-

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

A query comes to the backend via data packets arriving through

-TCP/IP or Unix Domain sockets. It is loaded into a string, and
-passed to the parser, where the
-lexical scanner, scan.l,
-breaks the query up into tokens(words). The parser uses 
-href="../../backend/parser/gram.y">gram.y and the tokens to
-identify the query type, and load the proper query-specific
-structure, like 
-href="../../include/nodes/parsenodes.h">CreateStmt or 
-href="../../include/nodes/parsenodes.h">SelectStmt.

-
-

The statement is then identified as complex (SELECT / INSERT /

-UPDATE / DELETE) or a simple, e.g  CREATE USER, ANALYZE, ,
-etc.  Simple utility commands are processed by statement-specific
-functions in backend/commands.
-Complex statements require more handling.

-
-

The parser takes a complex query, and creates a 

-href="../../include/nodes/parsenodes.h">Query structure that
-contains all the elements used by complex queries. Query.qual holds
-the WHERE clause qualification, which is filled in by 
-href="../../backend/parser/parse_clause.c">transformWhereClause().
-Each table referenced in the query is represented by a 
-href="../../include/nodes/parsenodes.h">RangeTableEntry, and
-they are linked together to form the range table of the
-query, which is generated by 
-href="../../backend/parser/parse_clause.c">transformFromClause().
-Query.rtable holds the query's range table.

-
-

Certain queries, like SELECT, return columns of data.

-Other queries, like INSERT and UPDATE, specify the
-columns modified by the query. These column references are
-converted to 
-href="../../include/nodes/primnodes.h">TargetEntry entries,
-which are linked together to make up the target list of the
-query. The target list is stored in Query.targetList, which is
-generated by 
-href="../../backend/parser/parse_target.c">transformTargetList().

-
-

Other query elements, like aggregates(SUM()), GROUP

-BY, and ORDER BY are also stored in their own Query
-fields.

-
-

The next step is for the Query to be modified by any

-VIEWS or RULES that may apply to the query. This is
-performed by the rewrite
-system.

-
-

The optimizer takes the

-Query structure and generates an optimal 
-href="../../include/nodes/plannodes.h">Plan, which contains the
-operations to be performed to execute the query. The 
-href="../../backend/optimizer/path">path module determines the
-best table join order and join type of each table in the
-RangeTable, using Query.qual(WHERE clause) to consider
-optimal index usage.

-
-

The Plan is then passed to the 

-href="../../backend/executor">executor for execution, and the
-result returned to the client. The Plan is actually as set of nodes,
-arranged in a tree structure with a top-level node, and various
-sub-nodes as children.

-
-

There are many other modules that support this basic

-functionality. They can be accessed by clicking on the
-flowchart.

-
-
-

Another area of interest is the shared memory area, which

-contains data accessible to all backends. It has recently used
-data/index blocks, locks, backend process information, and lookup
-tables for these structures:

-
-
    -
  • ShmemIndex - lookup shared memory addresses using structure
  • -names
    -
    -
  • Buffer
  • -Descriptor - control header for buffer cache block
    -
    -
  • Buffer
  • -Block - data/index buffer cache block
    -
    -
  • Shared Buffer Lookup Table - lookup of buffer cache block
  • -addresses using table name and block number( 
    -href="../../include/storage/buf_internals.h">BufferTag)
    -
    -
  • Lock Manager Tables (lock hash) - the 
    -href="../../include/storage/lock.h">LOCK structure, looked up
    -using a LOCKTAG.
    -A LOCK structure exists for each lockable object that is currently
    -locked by any backend.  Also, there is a subsidiary 
    -href="../../include/storage/lock.h">PROCLOCK structure for each
    -backend currently interested in a given LOCK
  • -
    -
  • PGPROC Structures -
  • -information about each backend, including locks held/waiting
    -
    -
    -

    Each data structure is created by calling 

    -href="../../backend/storage/ipc/shmem.c">ShmemInitStruct(), and
    -the lookups are created by 
    -href="../../backend/storage/ipc/shmem.c">ShmemInitHash().

    -
    -
    -Maintainer: Bruce Momjian (
    -
    -Last updated: Fri May  6 14:22:27 EDT 2005
    -
    -