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

diff --git a/doc/TODO b/doc/TODO
index 2f6176d2ba277014f7486aa258e01ad1f3b17b42..b577aafeaf5f676278dc0d140f7c51012cab607d 100644 (file)
--- a/doc/TODO
+++ b/doc/TODO
@@ -2,7 +2,7 @@
 PostgreSQL TODO List
 ====================
 Current maintainer:    Bruce Momjian ([email protected])
-Last updated:      Thu Feb  8 20:29:43 EST 2007
+Last updated:      Thu Feb  8 22:37:41 EST 2007
 
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -1329,27 +1329,7 @@ Miscellaneous Performance
   could hit disk before WAL is written.
 
 * Add a script to ask system configuration questions and tune postgresql.conf
-* 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
 * Consider ways of storing rows more compactly on disk
 
    o Support a smaller header for short variable-length fields?

diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html
index 99a0c2774517817ebcab87fe08ebb320b75000dd..5d9956c79ad51a370f0e2b99e6d0b54199de4536 100644 (file)
--- a/doc/src/FAQ/TODO.html
+++ b/doc/src/FAQ/TODO.html
@@ -8,7 +8,7 @@
 
 PostgreSQL TODO List
 Current maintainer:     Bruce Momjian ([email protected])
-Last updated:           Thu Feb  8 20:29:43 EST 2007
+Last updated:           Thu Feb  8 22:37:41 EST 2007
 
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -1189,26 +1189,7 @@ first.  There is also a developer's wiki at
   could hit disk before WAL is written.
 
   Add a script to ask system configuration questions and tune postgresql.conf
-  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
   Consider ways of storing rows more compactly on disk
   
     Support a smaller header for short variable-length fields?