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

From Florian G. Pflug
Subject Re: [HACKERS] Forcing current WAL file to be archived
Date
Msg-id 44CF1554.8060604@phlo.org
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.?

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 by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Re: Forcing current WAL file to be archived
Next
From: "Adrian Maier"
Date:
Subject: Re: [HACKERS] float8 regression failure (HEAD, cygwin)