postgres-xc-developers Mailing List for Postgres-XC

Hi All,

PFA which does first round of transaction management refactoring. Over
the time, the transaction management code at the coordinator had
become quite unreadable and error prone, so I made an attempt to clean
that up a bit. There are still some concerns marked with XXX or PGXC
TODO in the code, but I think the flow is now much better.

We track the nodes involved in global transaction as and when we send
BEGIN commands to the node. The nodes are tracked as either read-only
participant or read-write participants. This is important to later
decide whether do perform a 2PC or a simple commit on the remote
nodes. We right now rely on the planner information to (and the patch
does not change that much) to know if a transaction is doing any write
activity or not. This can be problematic in the presence of volatile
functions that can change the database state.

The decision to whether run a statement in auto-commit mode on the
data node or within a transaction block is also hard. We can run a
statement in auto-commit mode if and only if one data node is involved
in the transaction AND the statement will be sent to the data node
only once. Before this work, there were places where we were not
encapsulating statements in a transaction block possibly leading to
wrong results. After fixing this, there is a chance that we might see
some performance impact.

There are many cleanups: Here is a list, but probably not complete:

1. We now have only one member (transactionId) to track local or
global transaction identifier. Since we should always be using global
identifier in XC, this reduces the risk of wrong IDs being assigned
2. I removed the additional transaction state - TBLOCK_END_NOT_GTM. It
wasn't clear why we need this
3. 2PC is now hooked into PrepareTransaction/CommitTransaction.
Similarly, rollbacks and part commits are handled in AbortTransaction
4. The GTM transaction termination is handled in
Commit/AbortTransaction. That gives is a single entry point for
transaction management
5. Instead of various flags, we now just track if the local node is
involved in the transaction or not. That helps us decide whether to
perform 2PC on the local and remote node. This can further be enhanced
by looking at some other existing globals that PostgreSQL maintains
6. I have ripped off many other functions which are either not needed
now or probably needed for explicit 2PC. I will take another look at
them when I add back support for explicit 2PC

There is some further work needed regarding error handling. For
example, the combiner logic is cool to collect results from multiple
sources, but we fail to track errors at individual nodes. This might
be important to drive the 2PC even more cleanly. Another piece to look
at carefully is the places where we have hooked the remote transaction
handling. While I did not want to run remote communication while
interrupts are disabled, we need to ensure that this does not leave
any gaps in transaction management.

I have also attached a small patch that fixes some trivial bugs where
we were not setting the is_temp flag correctly at some places. I have
commented out an assertion which is really a PostgreSQL bug, but gets
highlighted when the explicit 2PC support is disabled.

Please look at the patches and let me know your comments.

Thanks,
Pavan



-- 
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com