recovery_target_time ignored ?
От | Venkata Balaji N |
---|---|
Тема | recovery_target_time ignored ? |
Дата | |
Msg-id | CAEyp7J8KMmYiLDuQqeUwGd+na_LoiEyHJxVGH0SLg_XoOsm9Bg@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: recovery_target_time ignored ?
|
Список | pgsql-hackers |
Hi,
Assuming that this might require a patch, i am posting this in pgsql-hackers. Apologies, if this is not the appropriate mailing list to start this discussion.
I performed a PITR and saw the below message in the log file is a bit confusing.2015-03-23 13:49:09.816 GMT-10 DB= PID=4707 LOG: database system was interrupted; last known up at 2015-03-23 10:30:26 GMT-10
2015-03-23 13:49:09.817 GMT-10 DB= PID=4707 LOG: starting point-in-time recovery to 2015-03-23 10:00:26+10
2015-03-23 13:49:09.827 GMT-10 DB= PID=4707 LOG: restored log file "000000010000000B00000020" from archive
2015-03-23 13:49:09.888 GMT-10 DB= PID=4707 LOG: redo starts at B/20000090
2015-03-23 13:49:09.937 GMT-10 DB= PID=4707 LOG: consistent recovery state reached at B/200000B8
2015-03-23 13:49:09.947 GMT-10 DB= PID=4707 LOG: restored log file "000000010000000B00000021" from archive
2015-03-23 13:49:09.950 GMT-10 DB= PID=4707 LOG: recovery stopping before commit of transaction 16267, time 2015-03-23 13:22:37.53007+10
The parameter recovery_target_time is ignored and recovery proceeds further applying all the available WAL Archive files finally ends up bringing up the database.
restore_command='cp /data/pgdata9400backup/pgwalarch9400backup/%f %p '
recovery_target_time='2015-03-23 10:00:26 GMT-10'
recovery_target_inclusive='true'
If this requires a patch, i would like to take it up.
Regards,
Venkata Balaji N
В списке pgsql-hackers по дате отправления: