Re: Forcing current WAL file to be archived - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: Forcing current WAL file to be archived
Date
Msg-id 200608011149.k71BnWq22892@momjian.us
Whole thread Raw
In response to Re: Forcing current WAL file to be archived  ("Albe Laurenz" <all@adv.magwien.gv.at>)
List 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 by date:

Previous
From: "Adrian Maier"
Date:
Subject: Re: [HACKERS] float8 regression failure (HEAD, cygwin)
Next
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] float8 regression failure (HEAD, cygwin)