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 ?  (David Steele <david@pgmasters.net>)
Список 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


By mistake i gave "recovery_target_time" as 10:00 GMT which is 25/30 minutes behind the backup start/end time registered in the backup_label.

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.

I think it would make sense if the recovery does not proceed any further and error out with a message like "recovery_target_time is behind the backup time.. please consider using the backup taken prior to the recovery_target_time"

recovery.conf file is as follows :

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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Zero-padding and zero-masking fixes for to_char(float)
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Table-level log_autovacuum_min_duration