Thank you Dhruv, Let me distil your answer
On Thu, Aug 13, 2026 at 11:49 PM Dhruv Aron <[email protected]> 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
