Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 6245D133798F for ; Wed, 27 Oct 2010 18:01:31 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 21775-05 for ; Wed, 27 Oct 2010 21:01:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from glacier.frostconsultingllc.com (glacier.frostconsultingllc.com [69.36.227.170]) by mail.postgresql.org (Postfix) with ESMTP id 1909B1335B36 for ; Wed, 27 Oct 2010 18:01:24 -0300 (ADT) Received: from dsl081-245-111.sfo1.dsl.speakeasy.net ([64.81.245.111] helo=Sidney-Stratton.local) by glacier.frostconsultingllc.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69) (envelope-from ) id 1PBD7V-0004Mo-Ey; Wed, 27 Oct 2010 14:01:19 -0700 Message-ID: <4CC8931D.3040800@agliodbs.com> Date: Wed, 27 Oct 2010 14:01:17 -0700 From: Josh Berkus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Simon Riggs CC: Robert Haas , Greg Stark , Bruce Momjian , pgsql-hackers@postgresql.org Subject: Re: Simplifying replication References: <201010220022.o9M0M8Q29438@momjian.us> <4CC0DEDE.7060707@agliodbs.com> <1288096049.1587.253.camel@ebony> In-Reply-To: <1288096049.1587.253.camel@ebony> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.419 tagged_above=-5 required=5 tests=BAYES_00=-1.9, FS_REPLICA=3.599, SARE_SPEC_REPLICA=0.72 X-Spam-Level: ** X-Archive-Number: 201010/1945 X-Sequence-Number: 172985 > You have to put the WAL files *somewhere* while you do the base backup. > PostgreSQL can't itself work out where that is, nor can it work out > ahead of time how big it will need to be, since it is up to you how you > do your base backup. Setting a parameter to -1 doesn't make the problem > go away, it just pretends and hopes it doesn't exist, but screws you > badly if you do hit the wall. Agreed. That's why I like the idea of having a max_wal_size/min_wal_time instead of keep_wal_segments or checkpoint_segments. It's relatively simple for a DBA to know how much disk space s/he has for WAL, total, before locking up the system. And to answer Robert's question, because now I understand what he was getting at. The reason we want a min_wal_time is because we don't want to keep a larger WAL around always. If more WAL were always better, then we'd only need max_wal_size and we'd only recycle when we hit it. Instead, we'd recycle whenever we passed max_wal_time. That's why I said that I was assuming nothing of the sort. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com