Re: Interaction of PITR backups and Bulk operationsavoiding WAL

Поиск
Список
Период
Сортировка
От Andreas Pflug
Тема Re: Interaction of PITR backups and Bulk operationsavoiding WAL
Дата
Msg-id 45F1931D.20200@pse-consulting.de
обсуждение исходный текст
Ответ на Re: Interaction of PITR backups and Bulk operationsavoiding WAL  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
>   
>> On Fri, 2007-03-09 at 11:15 -0500, Tom Lane wrote:
>>     
>>> It strikes me that allowing archive_command to be changed on the fly
>>> might not be such a good idea though, or at least it shouldn't be
>>> possible to flip it from empty to nonempty during live operation.
>>>       
>
>   
>> I'd rather fix it the proposed way than force a restart. ISTM wrong to
>> have an availability feature cause downtime.
>>     
>
> I don't think that people are very likely to need to turn archiving on
> and off on-the-fly.  Your proposed solution introduces a great deal of
> complexity (and risk of future bugs-of-omission, to say nothing of race
> conditions) to solve a non-problem.  We have better things to be doing
> with our development time.
>   
So how to do a file based backup without permanent archiving? If
pg_start_backup would turn on archiving temporarily with forcing
archiving all WAL files that contain open transactions, this would be
possible. This is what's requested for sites where PITR isn't needed,
just filesystem level backup. Currently, this can be mimicked somehow by
turning on archiving on-the-fly, hoping that all xactions are in the WAL
archive when pg_start_backup is issued (Simons mail shows how this will
fail).

Regards,
Andreas



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Simon Riggs"
Дата:
Сообщение: Re: Interaction of PITR backups and Bulkoperationsavoiding WAL
Следующее
От: Csaba Nagy
Дата:
Сообщение: Re: Interaction of PITR backups and Bulk operationsavoiding WAL