On Wed, Jul 1, 2020 at 4:02 PM Stephen Frost <sfrost@snowman.net> wrote:
> There's two solutions, really- first would be, as you suggest, configure
> PG to stay on the timeline that the backup was taken on, but I suspect
> that's often *not* what the user actually wants- what they really want
> is to restore an earlier backup (one taken before the TL switch) and
> then have PG follow the timeline switch when it comes across it.
It seems, though, that if it IS what the user actually wants, they're
now going to get the wrong behavior by default, and that seems pretty
undesirable.
> There's another option here, though I rejected it, which is that we
> could possibly force the restore to ignore a TL switch before reaching
> consistency, but if we do that then, sure, we'll finish the restore but
> we won't be on the TL that the user asked us to be, and we wouldn't be
> able to follow a primary that's on that TL, so ultimately the restore
> wouldn't actually be what the user wanted. There's really not an option
> to do what the user wanted except to find an earlier backup to restore,
> so that's why I'm proposing that if we hit this situation we just PANIC.
I'm not sure I really believe this. If someone tries to configure a
backup without inserting a non-default setting of
recovery_target_timeline, is it more likely that they want backup
restoration to fail, or that they want to recover from the timeline
that will let backup restoration succeed? You're arguing for the
former, but my instinct was the latter. Perhaps we need to hear some
other opinions.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
