diff --git a/doc/TODO b/doc/TODO
index cb0389adb6f..49beae20777 100644
--- a/doc/TODO
+++ b/doc/TODO
@@ -1,7 +1,7 @@
 PostgreSQL TODO List
 ====================
 Current maintainer:	Bruce Momjian (bruce@momjian.us)
-Last updated:		Mon Mar  3 10:06:41 EST 2008
+Last updated:		Mon Mar  3 13:45:12 EST 2008
 
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -138,11 +138,13 @@ Administration
 	  o Allow a warm standby system to also allow read-only statements
 	    [pitr]
 
-	    This is useful for checking PITR recovery.
 	    http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php
 
 	  o %Create dump tool for write-ahead logs for use in determining
 	    transaction id for point-in-time recovery
+
+	    This is useful for checking PITR recovery.
+
 	  o Allow recovery.conf to support the same syntax as
 	    postgresql.conf, including quoting
 
@@ -979,7 +981,8 @@ Indexes
 
 
 * Hash
-  http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php
+
+	  http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php
 
 	o Pack hash index buckets onto disk pages more efficiently
 
@@ -1234,6 +1237,13 @@ Write-Ahead Log
   tables probably cannot have indexes.  One complexity is the handling
   of indexes on TOAST tables.
 
+* Speed WAL recovery by allowing more than one page to be prefetched
+
+  This involves having a separate process that can be told which pages
+  the recovery process will need in the near future.
+  http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php
+
+
 
 Optimizer / Executor
 ====================
diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html
index b47d2564d80..750e64cb78f 100644
--- 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:bruce@momjian.us">bruce@momjian.us</a>)<br/>
-Last updated:           Mon Mar  3 10:06:41 EST 2008
+Last updated:           Mon Mar  3 13:45:12 EST 2008
 </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>.
@@ -128,11 +128,12 @@ first.  There is also a developer's wiki at<br/>
   <ul>
     <li>Allow a warm standby system to also allow read-only statements
             [<a href="http://momjian.postgresql.org/cgi-bin/pgtodo?pitr">pitr</a>]
-<p>            This is useful for checking PITR recovery.
-            <a href="http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php">http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php</a>
+<p>            <a href="http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php">http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php</a>
 </p>
     </li><li>%Create dump tool for write-ahead logs for use in determining
             transaction id for point-in-time recovery
+<p>            This is useful for checking PITR recovery.
+</p>
     </li><li>Allow recovery.conf to support the same syntax as
             postgresql.conf, including quoting
 <p>            <a href="http://archives.postgresql.org/pgsql-hackers/2006-12/msg00497.php">http://archives.postgresql.org/pgsql-hackers/2006-12/msg00497.php</a>
@@ -871,25 +872,26 @@ first.  There is also a developer's wiki at<br/>
           digital trees (see Aoki)
   </li></ul>
   </li><li>Hash
-  <a href="http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php">http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php</a>
-  <ul>
-    <li>Pack hash index buckets onto disk pages more efficiently
+</li></ul>
+<p>          <a href="http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php">http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php</a>
+</p>
+<ul>
+  <li>Pack hash index buckets onto disk pages more efficiently
 <p>          Currently only one hash bucket can be stored on a page. Ideally
           several hash buckets could be stored on a single page and greater
           granularity used for the hash algorithm.
 </p>
 <p>          <a href="http://archives.postgresql.org/pgsql-hackers/2004-06/msg00168.php">http://archives.postgresql.org/pgsql-hackers/2004-06/msg00168.php</a>
 </p>
-    </li><li>Consider sorting hash buckets so entries can be found using a
+  </li><li>Consider sorting hash buckets so entries can be found using a
           binary search, rather than a linear scan
-    </li><li>In hash indexes, consider storing the hash value with or instead
+  </li><li>In hash indexes, consider storing the hash value with or instead
           of the key itself
-    </li><li>Add WAL logging for crash recovery
-    </li><li>Allow multi-column hash indexes
-    </li><li>During index creation, pre-sort the tuples to improve build speed
+  </li><li>Add WAL logging for crash recovery
+  </li><li>Allow multi-column hash indexes
+  </li><li>During index creation, pre-sort the tuples to improve build speed
 <p>          <a href="http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php">http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php</a>
 </p>
-  </li></ul>
 </li></ul>
 <h1><a name="section_11">Fsync</a></h1>
 
@@ -1096,6 +1098,11 @@ first.  There is also a developer's wiki at<br/>
   crash recovery.  Readers can continue accessing the table.  Such
   tables probably cannot have indexes.  One complexity is the handling
   of indexes on TOAST tables.
+</p>
+  </li><li>Speed WAL recovery by allowing more than one page to be prefetched
+<p>  This involves having a separate process that can be told which pages
+  the recovery process will need in the near future.
+  <a href="http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php">http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php</a>
 </p>
 </li></ul>
 <h1><a name="section_17">Optimizer / Executor</a></h1>
