Тестирую процедуру непрерывного архивирования и восстановления БД.
Корректное восстановление происходит только в том случае, если скопировать WAL архив в каталог pg_xlog. Иначе (когда pg_xlog пуст) выдается ошибка:2015-11-11 16:09:49 MSK LOG: database system was interrupted; last known up at 2015-11-11 09:49:39 MSK
2015-11-11 16:09:49 MSK LOG: starting point-in-time recovery to "db-9.3.5-11.11.2015_ 9-39-45"
2015-11-11 16:09:49 MSK LOG: invalid primary checkpoint record
2015-11-11 16:09:49 MSK LOG: invalid secondary checkpoint record
2015-11-11 16:09:49 MSK PANIC: could not locate a valid checkpoint record
2015-11-11 16:09:49 MSK LOG: startup process (PID 7984) exited with exit code 3
2015-11-11 16:09:49 MSK LOG: aborting startup due to startup process failure
В документации про то что надо копировать WAL архив в каталог pg_xlog описание я не нашел. Что я делаю не так?
Или все так, но тогда где это в документации. Пока нету полной уверенности, что при падении сервера удастся его восстановить.
Конфиг recovery:
restore_command = 'copy "\\\\ss-10\\archivedir_test\\%f" "%p"'
recovery_end_command = 'echo finish'

Вопрос снят.
Удалил файл backup_label.
Этого делать нельзя.

Тестирую восстановление БД из резервной копии непрерывного архивирования. Восстановление работает: на заданное время (recovery_target_time = '2015-11-12 17:00:00 MSK') и полное восстановление (когда не указана ни один RECOVERY TARGET PARAMETERS).
Не работает восстановление при recovery_target_name = 'db-9.3.5-16.11.2015_16-35-19'. Нет ошибок. Восстановление идет до конца. Ошибок в логе нет.
recovery_target_name почему-то игнорируется (пропускается, не находится). Хотя в логе делается отметка о цели восстановления
Исходные данные:
9.3.5 на винде.
recovery.conf
restore_command = 'copy "\\\\ss-10\\archivedir_test\\%f" "%p"'
recovery_target_name = 'db-9.3.5-16.11.2015_16-35-19'.
файл *.*.backup (промежуточной базовой копии, до которой требуется восстановиться)
START WAL LOCATION: 51/BE000028 (file 0000001800000051000000BE)
STOP WAL LOCATION: 51/CDAC5040 (file 0000001800000051000000CD)
CHECKPOINT LOCATION: 51/BE000028
BACKUP METHOD: streamed
BACKUP FROM: master
START TIME: 2015-11-16 16:35:19 MSK
LABEL: db-9.3.5-16.11.2015_16-35-19
STOP TIME: 2015-11-16 16:44:33 MSK

Что не так?
Спасибо.

Сначало, я также подумал.
Поэтому попробовал использовать:
- pg_create_restore_point('db-9.3.5-16.11.2015_16-35-19')
- и утилиту pg_basebackup.exe -l "db-9.3.5-16.11.2015_16-35-19".
Оба способа дают один и тот же результат - LABEL: db-9.3.5-16.11.2015_16-35-19.

Не понятно, что не так.

авторСначало, я также подумал.
Поэтому попробовал использовать:
- pg_create_restore_point('db-9.3.5-16.11.2015_16-35-19')
- и утилиту pg_basebackup.exe -l "db-9.3.5-16.11.2015_16-35-19".
Оба способа дают один и тот же результат - LABEL: db-9.3.5-16.11.2015_16-35-19.

Я не прав, использовалась функция pg_start_backup('db-9.3.5-16.11.2015_16-35-19') вместо pg_create_restore_point.
LABEL не может выступать в качестве метки восстановления. Метка задается только pg_create_restore_point. Для утилиты pg_basebackup такая опция отсутствует.
Тема закрыта.