EvictUnpinnedBuffer and buffer free list

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: EvictUnpinnedBuffer and buffer free list
Date: 2025-01-31 05:15:54
Message-ID: CAExHW5tRzjmJ1At7BAb4VjiJMDmwiNTtx_DOhx96gYtSJvBS+g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

--
Best Wishes,
Ashutosh Bapat

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Lukas Fittl 2025-01-31 05:19:49 Re: [PATCH] Optionally record Plan IDs to track plan changes for a query
Previous Message Peter Smith 2025-01-31 05:09:46 Re: Introduce XID age and inactive timeout based replication slot invalidation