On 04.10.2012 20:07, Fujii Masao wrote:
On Thu, Oct 4, 2012 at 4:59 PM, Heikki Linnakangas
But I wonder why promoting a standby renders the backup invalid in the first
place? Fujii, Simon, can you explain that?
Simon had the same question and I answered it before.
http://archives.postgresql.org/message-id/cahgqgwfu04oo8yl5sucdjvq3brni7wtfzty9wa2kxtznhic...@mail.gmail.com
---------------------------------------
You say
"If the standby is promoted to the master during online backup, the
backup fails."
but no explanation of why?
I could work those things out, but I don't want to have to, plus we
may disagree if I did.
If the backup succeeds in that case, when we start an archive recovery from that
backup, the recovery needs to cross between two timelines. Which means that
we need to set recovery_target_timeline before starting recovery. Whether
recovery_target_timeline needs to be set or not depends on whether the standby
was promoted during taking the backup. Leaving such a decision to a user seems
fragile.
pg_control is backed up last, it would contain the new timeline. No need
to set recovery_target_timeline.
pg_basebackup -x ensures that all required files are included in the backup and
we can start recovery without restoring any file from the archive. But
if the standby is promoted during the backup, the timeline history
file would become
an essential file for recovery, but it's not included in the backup.
That is true. We could teach it to include the timeline history file,
though.
The situation may change if your switching-timeline patch has been committed.
It's useful if we can continue the backup even if the standby is promoted.
It wouldn't help with pg_basebackup -x, although it would allow
streaming replication to fetch the timeline history file.
I guess it's best to keep that restriction for now. But I'll add a TODO
item for this.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
