Greetings,
* Michael Banck (michael.banck@credativ.de) wrote:
> On Wed, Jul 01, 2020 at 12:12:14AM -0400, Stephen Frost wrote:
> > Specifically, if you take a backup off a primary and, while that backup
> > is going on, some replica is promoted and drops a .history file into the
> > WAL repo, that backup is no longer able to be restored with the new
> > recovery_target_timeline default.
>
> Quick question to grasp the magnitude of this:
>
> If a user takes a backup with pg_basebackup in streaming mode, would
> that still be a problem? Or is this "only" a problem for base backups
> which go through a wal archive common between primary and standby?
That's a bit complicated to answer.
1) If the pg_basebackup is taken off of the primary, or some
non-promoted replica, and the user fetches WAL during the backup and
does *not* configure a restore_command, then the backup should restore
just fine using the WAL that was fetched/streamed from the primary,
along the original timeline. Of course, that system won't be then able
to follow the new primary that was promoted during the backup.
2) If the pg_basebackup is taken off of the primary, or some other
replica, and the user *does* configure a restore_command, and a
promotion happens during the backup and that former-replica then pushes
a .history file into the repo that the restore_command is configured to
use, then I'm pretty sure this issue would be hit during the restore
(though I haven't specifically tested that, but we do go out and look
for timelines pretty early on).
3) If the pg_basebackup is taken off of the replica that's promoted, the
pg_basebackup will actually fail and error and there won't be a valid
backup in the first place.
Thanks,
Stephen