From 07f3168b761d44b71b66166cd0ea740508faa5ea Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 3 Apr 2009 18:17:43 +0000 Subject: [PATCH] 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 | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c index 856e482553..eb05435f79 100644 --- a/src/backend/storage/buffer/bufmgr.c +++ b/src/backend/storage/buffer/bufmgr.c @@ -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 */ } -- 2.39.5