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)
