Received: from localhost (unknown [200.46.204.183])
	by developer.postgresql.org (Postfix) with ESMTP id 3E6E82E0071
	for <pgsql-hackers-postgresql.org@developer.postgresql.org>;
	Wed, 11 Jun 2008 18:05:35 -0300 (ADT)
Received: from developer.postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 45224-10
	for <pgsql-hackers-postgresql.org@developer.postgresql.org>;
	Wed, 11 Jun 2008 18:05:27 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by developer.postgresql.org (Postfix) with ESMTP id D87F32E0047
	for <pgsql-hackers@postgresql.org>;
	Wed, 11 Jun 2008 18:05:30 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m5BL5Fxl011914;
	Wed, 11 Jun 2008 17:05:15 -0400 (EDT)
To: Alvaro Herrera <alvherre@commandprompt.com>
cc: Josh Berkus <josh@agliodbs.com>,
	Heikki Linnakangas <heikki@enterprisedb.com>, pgsql-hackers@postgresql.org,
	Robert Treat <xzilla@users.sourceforge.net>,
	Peter Eisentraut <peter_e@gmx.net>, Greg Smith <gsmith@gregsmith.com>,
	Andreas Pflug <pgadmin@pse-consulting.de>, Decibel! <decibel@decibel.org>
Subject: Re: Overhauling GUCS 
In-reply-to: <20080611163847.GN5352@alvh.no-ip.org> 
References: <48409D1E.3070208@agliodbs.com>
	<200806061624.29105.xzilla@users.sourceforge.net>
	<200806100937.38124.josh@agliodbs.com>
	<200806100949.17918.josh@agliodbs.com>
	<21875.1213122184@sss.pgh.pa.us>
	<484F7613.5070202@enterprisedb.com> <484FFF06.9010307@agliodbs.com>
	<20080611163847.GN5352@alvh.no-ip.org>
Comments: In-reply-to Alvaro Herrera <alvherre@commandprompt.com>
	message dated "Wed, 11 Jun 2008 12:38:47 -0400"
Date: Wed, 11 Jun 2008 17:05:15 -0400
Message-ID: <11913.1213218315@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200806/523
X-Sequence-Number: 119636

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Josh Berkus wrote:
>> Ideally, of course, there would be no wal_buffers setting, and WAL  
>> buffers would be allocated from shared_buffers pool on demand...

> Same for pg_subtrans, pg_clog, etc (as previously discussed)

I agree with that for pg_clog and friends, but I'm much more leery of
folding WAL into the same framework.  Its access pattern is *totally*
unlike standard caches, so the argument that this would be good for
performance is resting on nothing but imagination.  Also I'm concerned
about possible deadlocks, because WAL is customarily accessed while
holding one or more exclusive buffer locks.

			regards, tom lane