Re: Further reduction of bufmgr lock contention

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Further reduction of bufmgr lock contention
Дата
Msg-id 200605300129.k4U1T8022210@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: Further reduction of bufmgr lock contention  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Is this a TODO?

---------------------------------------------------------------------------

Tom Lane wrote:
> Josh Berkus <josh@agliodbs.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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
> 

--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Inefficient bytea escaping?
Следующее
От: Bruce Momjian
Дата:
Сообщение: pg_resetxlog -f flag