Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 59A8F1337B48 for ; Sun, 31 Oct 2010 18:12:54 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 95113-06 for ; Sun, 31 Oct 2010 21:12:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from acidenitrix.villemain.org (acidenitrix.villemain.org [91.121.90.165]) by mail.postgresql.org (Postfix) with ESMTP id 71DBE1336473 for ; Sun, 31 Oct 2010 18:12:42 -0300 (ADT) Received: from 89-158-241-48.rev.dartybox.com ([89.158.241.48] helo=DimIMac.local) by acidenitrix.villemain.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PCfCM-0001GU-BE; Sun, 31 Oct 2010 22:12:18 +0100 Received: by DimIMac.local (Postfix, from userid 501) id 3A97610FE8CD; Sun, 31 Oct 2010 22:12:12 +0100 (CET) From: Dimitri Fontaine To: Josh Berkus Cc: Simon Riggs , Robert Haas , Greg Stark , Bruce Momjian , pgsql-hackers@postgresql.org Subject: Re: Simplifying replication Organization: 2ndQuadrant References: <201010220022.o9M0M8Q29438@momjian.us> <4CC0DEDE.7060707@agliodbs.com> <1288096049.1587.253.camel@ebony> <4CC8931D.3040800@agliodbs.com> User-Mail-Address: dimitri@2ndQuadrant.fr Date: Sun, 31 Oct 2010 22:12:12 +0100 In-Reply-To: <4CC8931D.3040800@agliodbs.com> (Josh Berkus's message of "Wed, 27 Oct 2010 14:01:17 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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/2091 X-Sequence-Number: 173131 Josh Berkus writes: >> You have to put the WAL files *somewhere* while you do the base backup. > > 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. What if that somewhere is as easy to setup as a PostgreSQL archive cluster: set a GUC a two, start the server, then in the production server have archive_mode =3D on and use some internal archive and restore commands, like 'pg_archivewal -h host -p port =E2=80=A6'? It's only pushing the problem away, but in my mind the only reason why we're still talking about the problem is *not* the wal related settings but the current complexity of setting up a trustworthy archive server, and the number of external tools required in the operation (shell, scp, rsync, rm, etc=E2=80=A6). Or is it just me? Regards, --=20 Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support