Skip site navigation (1) Skip section navigation (2)

Re: Further reduction of bufmgr lock contention

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, Gavin Hamill <gdh(at)acentral(dot)co(dot)uk>
Subject: Re: Further reduction of bufmgr lock contention
Date: 2006-05-30 01:29:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Is this a TODO?


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

  Bruce Momjian

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-05-30 02:47:40
Subject: pg_resetxlog -f flag
Previous:From: Bruce MomjianDate: 2006-05-29 23:27:37
Subject: Re: Inefficient bytea escaping?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group