Update wording:

< could only see committed rows from another transaction. However, > could only see rows from another completed transaction. However, 981c981 < proper visibility of the row, for example, for cursors. > proper visibility of the row's cmin, for example, for cursors.

Update wording:
< could only see committed rows from another transaction. However, > could only see rows from another completed transaction. However, 981c981 < proper visibility of the row, for example, for cursors. > proper visibility of the row's cmin, for example, for cursors.
3bea1a35 · Bruce Momjian · da08559e · 3bea1a35 · 3bea1a35
隐藏空白更改
内联并排

Showing with 6 addition and 6 deletion

doc/TODO doc/TODO +3 -3

doc/src/FAQ/TODO.html doc/src/FAQ/TODO.html +3 -3

未找到文件。
--- a/doc/TODO
+++ b/doc/TODO
@@ -2,7 +2,7 @@
 PostgreSQL TODO List
 ====================
 Current maintainer:	Bruce Momjian (pgman@candle.pha.pa.us)
-Last updated:		Fri Sep  2 15:39:11 EDT 2005
+Last updated:		Fri Sep  2 15:51:34 EDT 2005

 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -972,13 +972,13 @@ Miscellaneous Performance
  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 committed rows from another transaction. However,
+  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, for example, for cursors.
+  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.

--- a/doc/src/FAQ/TODO.html
+++ b/doc/src/FAQ/TODO.html
@@ -8,7 +8,7 @@
 <body bgcolor="#FFFFFF" text="#000000" link="#FF0000" vlink="#A00000" alink="#0000FF">
 <h1><a name="section_1">PostgreSQL TODO List</a></h1>
 <p>Current maintainer:     Bruce Momjian (<a href="mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</a>)<br/>
-Last updated:           Fri Sep  2 15:39:11 EDT 2005
+Last updated:           Fri Sep  2 15:51:34 EDT 2005
 </p>
 <p>The most recent version of this document can be viewed at<br/>
 <a href="http://www.postgresql.org/docs/faqs.TODO.html">http://www.postgresql.org/docs/faqs.TODO.html</a>.
@@ -876,13 +876,13 @@ first.
  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 committed rows from another transaction. However,
+  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, for example, for cursors.
+  proper visibility of the row's cmin, for example, for cursors.
 </p>
 <p>  One possible solution is to create a phantom cid which represents a
  cmin/cmax pair and is stored in local memory.