Re: skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)
Date
Msg-id CA+TgmoaQTAktXercpUz6d-TyamQd=EZFQGqd+w4iF2Hd35Cw_A@mail.gmail.com
Whole thread Raw
In response to Re: skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Mon, Jun 8, 2015 at 12:09 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
>> Recently, one of our customers has had a basebackup fail because pg_log
>> contained files that were >8GB:
>> FATAL: archive member "pg_log/postgresql-20150119.log" too large for tar format
>>
>> I think pg_basebackup should also skip pg_log entries, as it does for
>> pg_stats_temp and pg_replslot, etc. I've attached a patch along those
>> lines for discussion.
>
> And a recent discussion about that is this one:
> http://www.postgresql.org/message-id/82897A1301080E4B8E461DDAA0FFCF142A1B2660@SYD1216
> Bringing the point: some users may want to keep log files in a base
> backup, and some users may want to skip some of them, and not only
> pg_log. Hence we may want more flexibility than what is proposed here.

That seems pretty thin.  If you're taking a base backup, your goal is
to create a standby.  Copying logs is in no way an integral part of
that, and we would not copy them if they were stored outside the data
directory.  If we accept the proposal that this needs to be more
complicated, will we also accept a proposal to make pg_basebackup
include relevant files from /var/log when the PostgreSQL logs are
stored there?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: replication slot restart_lsn initialization
Next
From: Nils Goroll
Date:
Subject: Re: s_lock() seems too aggressive for machines with many sockets