Re: [HACKERS] Forcing current WAL file to be archived

Поиск
Список
Период
Сортировка
Искать
От
Florian G. Pflug
Тема
Re: [HACKERS] Forcing current WAL file to be archived
Дата
Msg-id
44CF1554.8060604@phlo.org
Ответ на
Список
Дерево обсуждения
Re: Forcing current WAL file to be archived "Albe Laurenz" <all@adv.magwien.gv.at>
Re: Forcing current WAL file to be archived Bruce Momjian <bruce@momjian.us>
Re: [HACKERS] Forcing current WAL file to be archived "Florian G. Pflug" <fgp@phlo.org>
Albe Laurenz wrote:
> Tim Allen wrote:
>>>> Patch included to implement xlog switching, using an xlog record
>>>> "processing instruction" and forcibly moving xlog pointers.
>>>>
>>>> 1. Happens automatically on pg_stop_backup()
>>>
>>> Oh - so it will not be possible to do an online backup
>>> _without_ forcing a WAL switch any more?
>> Well, previously, you would have always had to simulate a wal 
>> switch, by 
>> working out which is the current wal file and copying that. Otherwise 
>> your online backup wouldn't be complete.
>>
>> What Simon is describing sounds like a big step forward from that 
>> situation. It should let me delete half the code in my pitr 
>> backup/failover scripts. Definitely a Good Thing.
> 
> Certainly a Good Thing, and it should be on by default.
> 
> But couldn't there be situations where you'd like to do an
> online backup without a WAL switch? To avoid generating an
> archive WAL every day on a database with few changes, e.g.?

But the online backup would be impossible to restore, if you don't
have enough wal archived to recover past the point where you called
pg_stop_backup().

So, doing a wal switch when pg_stop_backup() is called greatly reduces 
the risk of a user error that leads to broken backups.

greetings, Florian Pflug



В списке pgsql-patches по дате отправления
От: Albe Laurenz
Дата:
От: Adrian Maier
Дата:
FAQ