Greetings,
* Michael Banck (michael.ba...@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
Hi,
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_t
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jul 1, 2020 at 4:02 PM Stephen Frost 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 use
On Wed, Jul 1, 2020 at 4:02 PM Stephen Frost 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 earlie
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Jul 1, 2020 at 12:12 AM Stephen Frost wrote:
> > Among the changes made to PG's recovery in v12 was to set
> > recovery_target_timeline to be 'latest' by default. That's handy when
> > you're flipping back and forth between replic
On Wed, Jul 1, 2020 at 12:12 AM Stephen Frost wrote:
> Among the changes made to PG's recovery in v12 was to set
> recovery_target_timeline to be 'latest' by default. That's handy when
> you're flipping back and forth between replicas and want to have
> everyone follow that game, but it's made do
