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/CAHGQGwFU04oO8YL5SUcdjVq3BRNi7WtfzTy9wA2kXtZNHicTeA@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
