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-03 06:06:35
Message-ID: 0c552a0ee114314ceb026d65f75a98df3e8d22ff.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

magodo wrote:
> I read the document about recovery configuration, it says:

[...]

> Therefore, suppose I am going to recover to a point of some child
> timeline, to identify the point, I have to specify either
> recovery_target_name or recovery_target_time, and also specify the
> recovery_target_timeline.
>
> It is more like a tuple like (recovery_target_time,
> recovery_target_timeline), that specify a real point among all history
> branches. Am I understand this correctly?

I think you understood the concept well enough.

> If yes, what I want to ask is that, though the timeline is increasing
> between different recovery, but each timestamp corresponds to a
> timeline ID, one by one. So if I get a recovery_target_time, why should
> I still specify the recovery_target_timeline?
>
> Suppose following illustration:
>
> A B
> BASE-----+-----+------o1 (recover to A) 1
> | | C
> +.....|.......----+---o2 (regret, recover to B) 2
> | |
> +...........|..------o3 (regret again, recover to C) 3
> |
> +........---- 4

Consider this ^ point in time.
|

Suppose you specify this point in time as recovery_target_time.

Then it is not clear which of the timelines you want to follow.
The point of time exists in timeline 1, 2 and 3.

In other words, should recovery use the WAL from
0000000100000ABC00000012, 0000000200000ABC00000012 or 0000000300000ABC00000012?

By default, recovery will stay on the timeline where it started.
If you want to go to timeline 2 or 3, you have to specify
recovery_target_timeline.

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-03 06:12:30 Re: pg_sleep() inside plpgsql block - pro & cons
Previous Message Adrian Klaver 2018-10-02 23:27:46 Re: FTS trigger works 1 at a time, but fails with bulk insert script