Re: Restructured Shared Buffer Hash Table

Thank you Dhruv,

Let me distil your answer

On Thu, Aug 13, 2026 at 11:49 PM Dhruv Aron <dhruv(dot)aron(at)gmail(dot)com> wrote:

> Without the spinlock change, a concurrent backend can overwrite the entry
> slot that is supposed to be deleted imminently after the header lock is
> released, corrupting the bucket chains.
>
And

> This is not an issue with dynahash because it allocates new entries via
> the freelist, which safely allows inserting a new entry while the stale one
> waits to be deleted.
>
------

Simple idea

An alternative would be to pin the buffers instead.

* StrategyGetBuffer
*
* Called by the bufmgr to get the next candidate buffer to use in
* GetVictimBuffer(). The only hard requirement GetVictimBuffer() has is
that
* the selected buffer must not currently be pinned by anyone.

InvalidateVictimBuffer is safe, because the buffer is pinned. But
InvalidateBuffer
is not, as it deletes while refcount==0, when a concurrent GetVictimBuffer
could
take it.

Ambitious idea (food for thought):

What if we don't remove it from the BufTable, WaitIO if needed,
Reset BUF_USAGECOUNT_MASK and return?
No LWLock required, the buffer would be removed from BufTable later
by InvalidateVictimBuffer.

Maybe we could get rid of the buffer scan too?
Lock the relation so that no one can start any IO on it.
Wait for every I/O in progress.
Ready

Just let them be reused naturally on on the next clock sweeps

Andres, do you want to educate us as to why the above ideas could be
terrible?

Regards,
Alexandre