Re: skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)
Дата
Msg-id CA+TgmoaQTAktXercpUz6d-TyamQd=EZFQGqd+w4iF2Hd35Cw_A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)
Список 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 по дате отправления:

Предыдущее
От: Gurjeet Singh
Дата:
Сообщение: Re: replication slot restart_lsn initialization
Следующее
От: Nils Goroll
Дата:
Сообщение: Re: s_lock() seems too aggressive for machines with many sockets