Message-ID: <55C3C073.4000207@gmx.net>
Date: Thu, 06 Aug 2015 16:15:47 -0400
From: Peter Eisentraut <peter_e@gmx.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Kevin Grittner <kgrittn@ymail.com>, John Scalia <jayknowsunix@gmail.com>,
 "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Subject: Re: pg_basebackup problem...
References: 
 <CABzCKRBUsSw+B3kQa8RCKx3D_LMg=A4hUS05=L5hamFP01BJgA@mail.gmail.com>
 <2095928829.121339.1438879776368.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <2095928829.121339.1438879776368.JavaMail.yahoo@mail.yahoo.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

On 8/6/15 12:49 PM, Kevin Grittner wrote:
>> 2) If a WAL segment is in fact required for the backed up DB to
>> > start, why would pg_basebackup not include those by default? To
>> > not do so, doesn't create a backup file, just in this case, a
>> > tarball that's worthless.
> ... unless you are archiving the WAL to somewhere that it will be
> kept long enough to be usable for such purposes.  If you are (and I
> highly recommend that you do so), including WAL in the base backup
> is a waste of both bandwidth and storage space.

This is arguably an artifact of the evolution of replication in
PostgreSQL.  You used to do tar backup + archiving, then you could
switch to pg_basebackup + archiving, and nowadays you could switch to
pg_basebackup without archiving, but the default behavior of
pg_basebackup still caters to the old case.


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin