Re: how to identify the timeline of specified recovery_target_time when do multiple PITR

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: magodo <wztdyl(at)sina(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: how to identify the timeline of specified recovery_target_time when do multiple PITR
Date: 2018-10-11 04:35:06
Message-ID: ccbdaf1d321cb8e8f21ab93ad6915757d3b5dfe5.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

magodo wrote:
> OK... Just take another example:
>
> A B
> BASE-----+-----+------o1 (recover to A) 1
> | | C
> +.....|.......----+---o2 (regret, recover to B) 2
> | |
> +...........|..------o3 (regret again, recover to C) 3
> |
> +........---- 4
>
>
> Suppose I'm at "o3" and want to recover to point "C". Because I want to
> recover to the first timeline which covers this time point, it means I
> wish to recover to timeline 2.

Ah, I finally understand your question.

You assume tht timeline 1 and 2 have ended (that's how you drew it),
and that consequently timeline 3 is the "earliest existing" timeline,
so why doesn't PostgreSQL choose that one automatically?

Even though you drew it that way, timeline 1 and 2 have not ended, in
a way. There may be more on them. How should PostgreSQL know what is
the last WAL entry on a certain timeline? For that, it would have to
restore and examine *all* WAL segments on that timeline until that fails.

But that is unreasonable because of the potential amount of time
and work involved. Rather, PostgreSQL has to decide at the point where
timeline 2 branches off which one it should follow.

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2018-10-11 04:44:08 Re: Please let me know which configuration setting we need to modify to speedup the pg_dump backup.
Previous Message Raghavendra Rao J S V 2018-10-11 03:16:13 Re: Please let me know which configuration setting we need to modify to speedup the pg_dump backup.