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)
Список
Дерево обсуждения
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 по дате отправления