On Fri, Jan 31, 2025 at 2:19 PM Yura Sokolov <y.soko...@postgrespro.ru> wrote: > > 31.01.2025 08:15, Ashutosh Bapat пишет: > > Hi All, > > EvictUnpinnedBuffer() calls InvalidateVictimBuffer() followed by > > UnpinBuffer() before returning. None of those functions put the buffer > > back into the free list. Its freeNext remains set to > > FREENEXT_NOT_IN_LIST. I think then that buffer will never be used and > > lost forever. I know that that function is only meant for development > > or testing but even while testing something losing a buffer forever > > seems like a problem. > > > > The prologue of function InvalidateVictimBuffer() says "/* Helper > > routine for GetVictimBuffer() ". I believe that it's expected that the > > buffer will be allocated to some other page, and that's why it doesn't > > return the buffer to the free list. But in the case of > > EvictUnpinnedBuffer() we are not using that buffer for any page, so it > > must be returned to the free list. InvalidateBuffer() does that but > > its prologue mentions that it's supposed to be used when freeing > > buffers for relations and databases. > > > > I think there are two solutions > > 1. Use InvalidBuffer() instead of InvalidateVictimBuffer(). But I am > > not sure whether that's safe or what other safety measures we have to > > put in EvictUnpinnedBuffer() > > 2. Call StrategyFreeBuffer() after InvalidateVictimBuffer() > > > > Thoughts? > > Clock eviction algorithm visit every page (by StrategyGetBuffer), so it > will eventually observe this buffer and use it for new page. >
yes, that's correct. That does reduce the intensity of problem very much. However, a backend which would otherwise be able to get a buffer from freelist will be forced to evict some other useful buffer. This may show unexpected results even in testing/development experiments being carried out. -- Best Wishes, Ashutosh Bapat
