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

Re: Further reduction of bufmgr lock contention

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: josh(at)agliodbs(dot)com
Cc: 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-24 19:25:26
Message-ID: 909.1148498726@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Andreas Joseph KroghDate: 2006-05-24 19:32:31
Subject: Re: file-locking and postmaster.pid
Previous:From: Magnus HaganderDate: 2006-05-24 19:18:07
Subject: Re: Why is CVS server so slow?

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