Add a comment documenting the question of whether PrefetchBuffer should

try to protect an already-existing buffer from being evicted.  This was
left as an open issue when the posix_fadvise patch was committed.  I'm
not sure there's any evidence to justify more work in this area, but we
should have some record about it in the source code.

diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index 4a7dda3edbbabd882455eb4539ac8dfe75b25068..da5f8a74146282364e1724d0b10251a05f9457a9 100644 (file)
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *       $PostgreSQL: pgsql/src/backend/storage/buffer/bufmgr.c,v 1.250 2009/03/31 22:12:48 tgl Exp $
+ *       $PostgreSQL: pgsql/src/backend/storage/buffer/bufmgr.c,v 1.251 2009/04/03 18:17:43 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -153,6 +153,18 @@ PrefetchBuffer(Relation reln, ForkNumber forkNum, BlockNumber blockNum)
                /* If not in buffers, initiate prefetch */
                if (buf_id < 0)
                        smgrprefetch(reln->rd_smgr, forkNum, blockNum);
+
+               /*
+                * If the block *is* in buffers, we do nothing.  This is not really
+                * ideal: the block might be just about to be evicted, which would
+                * be stupid since we know we are going to need it soon.  But the
+                * only easy answer is to bump the usage_count, which does not seem
+                * like a great solution: when the caller does ultimately touch the
+                * block, usage_count would get bumped again, resulting in too much
+                * favoritism for blocks that are involved in a prefetch sequence.
+                * A real fix would involve some additional per-buffer state, and
+                * it's not clear that there's enough of a problem to justify that.
+                */
        }
 #endif /* USE_PREFETCH */
 }