Update TODO description:

* Speed WAL recovery by allowing more than one page to be prefetched

  This should be done utilizing the same infrastructure used for
  prefetching in general to avoid introducing complex error-prone code
  in WAL replay.

diff --git a/doc/TODO b/doc/TODO
index a88e56a082cb21a11842bfa2486a97effa920e08..4e2b8ed6d6e917a4697352764f8aeb292d7fac5a 100644 (file)
--- a/doc/TODO
+++ b/doc/TODO
@@ -1,7 +1,7 @@
 PostgreSQL TODO List
 ====================
 Current maintainer:    Bruce Momjian ([email protected])
-Last updated:      Tue Mar 18 14:40:32 EDT 2008
+Last updated:      Tue Mar 18 19:32:48 EDT 2008
 
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -1510,8 +1510,9 @@ Write-Ahead Log
 
 * 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.
+  This should be done utilizing the same infrastructure used for
+  prefetching in general to avoid introducing complex error-prone code
+  in WAL replay.
   http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php
   http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php
   http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php

diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html
index ab1f88622262858636847b781e5efc14c2e86d2f..4255c6a0b1671933a79b1d49be2642cf360fda3b 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:           Tue Mar 18 14:40:32 EDT 2008
+Last updated:           Tue Mar 18 19:32:48 EDT 2008
 
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -1312,8 +1312,9 @@ first.  There is also a developer's wiki at
   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.
+  This should be done utilizing the same infrastructure used for
+  prefetching in general to avoid introducing complex error-prone code
+  in WAL replay.
   http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php
   http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php
   http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php