Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 9C81D2E0068 for ; Wed, 11 Jun 2008 22:12:36 -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 50935-02-2 for ; Wed, 11 Jun 2008 22:12:10 -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 065A32E0040 for ; Wed, 11 Jun 2008 22:02:34 -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 m5C12K2F025598; Wed, 11 Jun 2008 21:02:20 -0400 (EDT) To: Gregory Stark cc: "Alvaro Herrera" , "Josh Berkus" , "Heikki Linnakangas" , pgsql-hackers@postgresql.org, "Robert Treat" , "Peter Eisentraut" , "Greg Smith" , "Andreas Pflug" , "Decibel!" Subject: Re: Overhauling GUCS In-reply-to: <87od674hy6.fsf@oxford.xeocode.com> 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> <11913.1213218315@sss.pgh.pa.us> <87od674hy6.fsf@oxford.xeocode.com> Comments: In-reply-to Gregory Stark message dated "Thu, 12 Jun 2008 01:26:09 +0100" Date: Wed, 11 Jun 2008 21:02:20 -0400 Message-ID: <25597.1213232540@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/538 X-Sequence-Number: 119651 Gregory Stark writes: > "Tom Lane" writes: >> I agree with that for pg_clog and friends, but I'm much more leery of >> folding WAL into the same framework. > Well it may still be worthwhile stealing buffers from shared_buffers even if > we set a special flag marking them as owned by WAL and out of bounds for > the normal buffer manager. > At least that way we could always steal more if we want or return some, as > long as we're careful about when we do it. ... and as long as you can acquire the WAL per-buffer management space out of nowhere ... regards, tom lane