No, it's super frustrating. While I do the recovery, it says it reaches a
consistent recovery state, and i just cannot find a way how to convince pg
to stop at that state:
2013-08-02 09:23:25 GMT DEBUG: postgres: PostmasterMain: initial
environment dump:
2013-08-02 09:23:25 GMT DEBUG:
Klaus Ita wrote:
>>> I have restored a Database Cluster with a recovery_target_time set to
>>>
>>> recovery_target_time = '2013-07-27 21:20:17.127664+00'
>>> recovery_target_inclusive = false
>>>
>>>
>>>
>>> now it seems the restore rather restored to some point in time (rather the
>>> 18th than
2013-07-30 11:15:15 UTC <%> LOG: starting point-in-time recovery to
2013-07-27 21:20:17.127664+00
2013-07-30 11:15:15 UTC <%> LOG: restored log file
"00010230005C" from archive
2013-07-30 11:15:15 UTC <%> LOG: restored log file
"00010230005A" from archive
2013-07-30 11:15
Klaus Ita wrote:
> I have restored a Database Cluster with a recovery_target_time set to
>
> recovery_target_time = '2013-07-27 21:20:17.127664+00'
> recovery_target_inclusive = false
>
>
>
> now it seems the restore rather restored to some point in time (rather the
> 18th than the 27th). Is
Hello PG Experts!
I have restored a Database Cluster with a recovery_target_time set to
recovery_target_time = '2013-07-27 21:20:17.127664+00'
recovery_target_inclusive = false
now it seems the restore rather restored to some point in time (rather the
18th than the 27th). Is there an explanati
