]> granicus.if.org Git - postgresql/commit
Done!
authorBruce Momjian <bruce@momjian.us>
Fri, 9 Feb 2007 03:37:45 +0000 (03:37 +0000)
committerBruce Momjian <bruce@momjian.us>
Fri, 9 Feb 2007 03:37:45 +0000 (03:37 +0000)
commit19d561cbd00f5fd2a342fbcec4d4f5b9b28bf27d
tree6b2b1118fda05af356d6526427dc4cf8f11b9c9d
parentc398300330cb3060d50652800dbd12729ab9f5ef
Done!

< * Merge xmin/xmax/cmin/cmax back into three header fields
<
<   Before subtransactions, there used to be only three fields needed to
<   store these four values. This was possible because only the current
<   transaction looks at the cmin/cmax values. If the current transaction
<   created and expired the row the fields stored where xmin (same as
<   xmax), cmin, cmax, and if the transaction was expiring a row from a
<   another transaction, the fields stored were xmin (cmin was not
<   needed), xmax, and cmax. Such a system worked because a transaction
<   could only see rows from another completed transaction. However,
<   subtransactions can see rows from outer transactions, and once the
<   subtransaction completes, the outer transaction continues, requiring
<   the storage of all four fields. With subtransactions, an outer
<   transaction can create a row, a subtransaction expire it, and when the
<   subtransaction completes, the outer transaction still has to have
<   proper visibility of the row's cmin, for example, for cursors.
<
<   One possible solution is to create a phantom cid which represents a
<   cmin/cmax pair and is stored in local memory.  Another idea is to
<   store both cmin and cmax only in local memory.
<
> * -Merge xmin/xmax/cmin/cmax back into three header fields
doc/TODO
doc/src/FAQ/TODO.html