Transaction system (proposal for 6.5)

Hi...


    I was thinking in a major rewrite of the PostrgreSQL transaction
system, in order to provide less tuple overhead and recoverabilty.

    My first goal is to reduce tuple overhead, getting rid of xmin/xman and
cmin/cmax. To provide this functionality, I'm planning to keep only a
flag indicating if the transaction is in curse or not. If, during a
transaction, a certain tuple is affected, this flag will store the
current transaction id. Thus, if this tuple is commited, an invalid OID
(say, 0), will be written to this flag.

    The only problem a saw using this approach is if some pages got flushed
during the transaction, because these pages will have to be reload from
disk.

    To address the problem of non-functional update, I pretend to store a
command identifier with the tuple, and, during update, see if the cid of
a tuple is equal of the current cid of this transaction (like we do
today).

    To keep track of current transactions, there will have a list of tuples
affected by this transaction, and the operation executed. This way,
during commit, we only confirm these operations in relations (writing an
invalid OID in current xid of each tuple affected). To rollback, we
delete the new tuples (and mark this operation as a commit) and mark the
old tuples affected as "live" (and leave these commited).

    I'm thinking of leave a transaction id for each new backend, and
postmaster will keep track of used transaction ids. This way, there is
no need to keep a list of transactions in shared memory.

    For recovery (my second goal), I pretend to, at startup of postmaster,
to rollback all marked in-curse transactions. After that, I'm thinking
about a redo log, but I'm still searching a way to keep it with the
minimum size possible.

  Sugestions? Comments?

        Robson.