mirrors
/
postgres
mirror of https://github.com/postgres/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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.
This commit is contained in:
Bruce Momjian 2005-09-02 19:51:37 +00:00
parent da08559e9b
commit 3bea1a353f
2 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/TODO
View File

@ -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.

6
doc/src/FAQ/TODO.html
View File

@ -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.