Received: from localhost (maia-5.hub.org [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 4273D9FB400
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Sat, 21 Jul 2007 00:57:15 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 23346-06 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Sat, 21 Jul 2007 00:57:11 -0300 (ADT)
X-Greylist: delayed 00:25:51.40667 by SQLgrey-1.7.5
Received: from skunk.mtbrook.bozemanpass.com (skunk.mtbrook.bozemanpass.com
	[69.145.82.195])
	by postgresql.org (Postfix) with ESMTP id DF7149FB3CF
	for <pgsql-performance@postgresql.org>;
	Sat, 21 Jul 2007 00:57:11 -0300 (ADT)
Received: from [69.145.82.254] (unknown [69.145.82.254])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by skunk.mtbrook.bozemanpass.com (Postfix) with ESMTP id E2B3D55829C;
	Fri, 20 Jul 2007 20:31:18 -0700 (PDT)
Message-ID: <46A17E02.2090807@boreham.org>
Date: Fri, 20 Jul 2007 21:31:14 -0600
From: David Boreham <david_list@boreham.org>
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: "Jignesh K. Shah" <J.K.Shah@Sun.COM>, Josh Berkus <josh@agliodbs.com>,
	pgsql-performance@postgresql.org,
	Alvaro Herrera <alvherre@commandprompt.com>
Subject: Re: User concurrency thresholding: where do I look?
References: <200707190828.59088.josh@agliodbs.com>
	<200707191819.13899.josh@agliodbs.com>
	<15685.1184895926@sss.pgh.pa.us>
	<200707192138.39679.josh@agliodbs.com>
	<46A0FA31.2080208@sun.com> <12002.1184955831@sss.pgh.pa.us>
	<46A1055F.9010304@sun.com> <12445.1184958793@sss.pgh.pa.us>
	<46A11116.5030905@sun.com> <14909.1184962561@sss.pgh.pa.us>
	<46A1205B.8010205@sun.com> <15343.1184965054@sss.pgh.pa.us>
In-Reply-To: <15343.1184965054@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200707/281
X-Sequence-Number: 25965

Tom Lane wrote:
> Having malloc/free use
> an internal mutex is necessary in multi-threaded programs, but the
> backend isn't multi-threaded.  
>   
Hmm...confused. I'm not following why then there is contention for the 
mutex.
Surely this has to be some other mutex that is in contention, not a heap 
lock ?

It'd be handy to see the call stack for the wait state -- if the thing 
is spending
a significant proportion of its time in contention it should be easy to 
get that with
a simple tool such as pstack or a debugger.