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.

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 */
 }