mirror of
https://github.com/postgres/postgres.git
synced 2025-07-15 19:21:59 +03:00
b26329654e
is in progress on the same hashtable. This seems the least invasive way to fix the recently-recognized problem that a split could cause the scan to visit entries twice or (with much lower probability) miss them entirely. The only field-reported problem caused by this is the "failed to re-find shared lock object" PANIC in COMMIT PREPARED reported by Michel Dorochevsky, which was caused by multiply visited entries. However, it seems certain that mdsync() is vulnerable to missing required fsync's due to missed entries, and I am fearful that RelationCacheInitializePhase2() might be at risk as well. Because of that and the generalized hazard presented by this bug, back-patch all the supported branches. Along the way, fix pg_prepared_statement() and pg_cursor() to not assume that the hashtables they are examining will stay static between calls. This is risky regardless of the newly noted dynahash problem, because hash_seq_search() has never promised to cope with deletion of table entries other than the just-returned one. There may be no bug here because the only supported way to call these functions is via ExecMakeTableFunctionResult() which will cycle them to completion before doing anything very interesting, but it seems best to get rid of the assumption. This affects 8.2 and HEAD only, since those functions weren't there earlier.
*******************************************************************************
* *
* 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
The current node structures are plain old C structures. "Inheritance" is
achieved by convention. No additional functions will be generated. Functions
that manipulate node structures reside in this directory.
FILES IN THIS DIRECTORY
Node manipulation functions:
copyfuncs.c - copying a node
equalfuncs.c - comparing a node
outfuncs.c - convert a node to ascii representation
readfuncs.c - convert ascii representation back to a node
makefuncs.c - creator functions for primitive nodes
Node definitions:
nodes.h - define node tags (NodeTag)
pg_list.h - generic list
primnodes.h - primitive nodes
parsenodes.h - parse tree nodes
plannodes.h - plan tree nodes
relation.h - inner plan tree nodes
execnodes.h - executor nodes
memnodes.h - memory nodes
STEPS TO ADD A NODE
Suppose you wana define a node Foo:
1. add a tag (T_Foo) to the enum NodeTag in nodes.h (You may have to
recompile the whole tree after doing this.)
2. add the structure definition to the appropriate ???nodes.h file. If you
intend to inherit from, say a Plan node, put Plan as the first field of
you definition.
3. if you intend to use copyObject, equal, nodeToString or stringToNode,
add an appropriate function to copyfuncs.c, equalfuncs.c, outfuncs.c
and readfuncs.c accordingly. (Except for frequently used nodes, don't
bother writing a creator function in makefuncs.c)
HISTORICAL NOTE
Prior to the current simple C structure definitions, the Node structures
uses a pseudo-inheritance system which automatically generates creator and
accessor functions. Since every node inherits from LispValue, the whole thing
is a mess. Here's a little anecdote:
LispValue definition -- class used to support lisp structures
in C. This is here because we did not want to totally rewrite
planner and executor code which depended on lisp structures when
we ported postgres V1 from lisp to C. -cim 4/23/90