Nested transactions

Hackers,

Here is the latest installment of the nested transactions patch.

What's in the current patch:

- transaction block support. The user can start subtransactions inside
each transaction block and rollback each one independently. The
nesting level has no practical limit, though each transaction tree can
have at most 2^32 commands (subtransaction start counts as one
command).

- Most subsystems have a cleanup function called at subtransaction
abort: deferred triggers, relcache refcount, catcache refcount, smgr
pending deletes, gist/rtree/hash scan lists, bufmgr refcount,
on-commit actions.

- SPI closes connections opened during the aborting subtransaction.

- The lock manager releases locks taken by the aborting subtransaction,
but _holds_ locks taken by a committing subtransaction. This is
needed by MVCC semantics.

- A special memory context, CommitContext is created for each
subtransaction. It is destroyed if the subtransaction aborts, but
if it commits then it will be kept until main transaction commit
(or its parent subtransaction aborts).

- The pg_subtrans module is created to keep the parent Xid of each
subtransaction. It's similar (and based on) the pg_clog code.

- The pg_clog Xlog code was moved to Slru and merged with pg_subtrans
Xlog code.

- When we wait for a transaction to finish (XactLockTableWait), we
actually wait for the topmost transaction.

- SET TRANSACTION ISOLATION LEVEL and SET READ ONLY are not allowed
inside a subtransaction.

What's missing to complete the nested transactions work:

- Make GUC vars work correctly.
- Lots of testing.
- Documentation
- Optimizations:
* the phantom Xid idea is not implemented here.
* optimize TransactionIdIsInProgress
* profile
- More regression testing. Need additional concurrent infrastructure.

Many thanks to:

- Manfred Koizar for making the pg_subtrans code possible and discussion
on several issues.
- Stephan Szabo for the idea on which the deferred trigger code was
based.
- Tom Lane for asking the right questions.
- Bruce Momjian for useful ideas.

IMHO this patch should be reviewed and applied to achieve wide testing
as soon as possible before feature freeze. More changes can be applied
later as available/needed. (The patch is already huge and contains
several important changes that need careful review. Adding more to the
mix will only make things more difficult.)

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"No single strategy is always right (Unless the boss says so)"
(Larry Wall)