Transaction block states

Hackers,

I've been drawing a directed graph which shows the transaction block
states (the TBLOCK_* symbols in access/transam/xact.c) as currently
implemented, and how it will be if I add states to represent
subtransactions.

To read it, keep in mind that I ommited the TBLOCK_ prefix so the graph
could fit my screen.  I also had to use a very small font size.


The current state of affairs is shown in current_tblock.png.  It's not
particularly hard.  Nodes are states, edges are functions.  In
parentheses I show what low-level functions they call.  Note that I show
a single edge with multiple labels, comma-separated, when there was more
than one edge going between the same start and end nodes.  (For example,
from TBLOCK_ENDABORT to TBLOCK_DEFAULT there are two routes, one by
calling CommitTransactionCommand and the other via
AbortCurrentTransaction; both of them execute CleanupTransaction).

Nodes in red indicate places where the user is allowed to interact.

Note that I don't mention the TRANS_ "low level" states *at all*; they
are completely redundant to me, and I think they should be eliminated
completely, as the TBLOCK_ states are enough to identify the overall
state.



The second graph, new_tblock.png, shows several additional nodes.
I didn't try too hard, but this one won't fit my screen no matter what.
There are two nodes labelled "child" and "parent"; those are not TBLOCK
states at all, but rather correspond to exchange points between a
subtransaction level and the next or previous.  Anything passing through
them has to execute PushCurrentTransaction() or PopTransaction() to
modify the transaction-state stack.


I think the GraphViz's dot source I used to generate this should be
included in the source distribution, because this subsystem will be very
hard to understand without it ...

Comments?  Am I forgetting something?

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Aprender sin pensar es inútil; pensar sin aprender, peligroso" (Confucio)