From: | Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: EvictUnpinnedBuffer and buffer free list |
Date: | 2025-01-31 08:49:36 |
Message-ID: | 777ee515-2c1d-4384-a881-a402c920c8be@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2025-01-31 08:51:26 | Re: Non-text mode for pg_dumpall |
Previous Message | Amit Langote | 2025-01-31 08:31:44 | Re: generic plans and "initial" pruning |