Re: Further reduction of bufmgr lock contention

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> BTW, we're going to be testing this patch on Sun Niagara servers. What's
> the outstanding bug with it? I don't quite follow.

It's not acceptable as-is because of the risk of running out of shared
memory for hashtable entries. In the existing code, there's a clear
upper bound on the number of entries in the block-number-to-buffer hash
table, ie, shared_buffers + 1 (the +1 because we acquire the new entry
before releasing the old when reassigning a buffer). With multiple
hashtables serving subsets of the buffers, the different tables might
at different times need different numbers of entries, and that makes it
a lot harder to be sure you won't run out of memory. I don't say it's
insoluble, but the current patch wasn't even claimed to be safe by its
author...

regards, tom lane