Re: EvictUnpinnedBuffer and buffer free list - Mailing list pgsql-hackers

From Yura Sokolov
Subject Re: EvictUnpinnedBuffer and buffer free list
Date
Msg-id 777ee515-2c1d-4384-a881-a402c920c8be@postgrespro.ru
Whole thread Raw
In response to EvictUnpinnedBuffer and buffer free list  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: EvictUnpinnedBuffer and buffer free list
List pgsql-hackers
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.




pgsql-hackers by date:

Previous
From: Nazir Bilal Yavuz
Date:
Subject: Re: Show WAL write and fsync stats in pg_stat_io
Next
From: jian he
Date:
Subject: Re: Non-text mode for pg_dumpall