Re: Forcing current WAL file to be archived
От | Bruce Momjian |
---|---|
Тема | Re: Forcing current WAL file to be archived |
Дата | |
Msg-id | 200608011149.k71BnWq22892@momjian.us обсуждение исходный текст |
Ответ на | Re: Forcing current WAL file to be archived ("Albe Laurenz" <all@adv.magwien.gv.at>) |
Список | pgsql-patches |
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.? > > Maybe not, I'm just wondering. Considering the I/O caused by the backup, a new WAL file seems insignificant, and until a log switch, the backup isn't useful. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-patches по дате отправления: