Если вы настраивали по методичке, то ничего кривого не может быть.

Методички по кластеру нет...

Судя по мурзилке, это просто счетчик количества созданных временных файлов с момента старка кластера ПГ, т.е. не срез в моменте. Причем созданных любыми способами, как в целях запросов 1с, так и в целях сборщика статистики и других процессов обслуживания.

В методичке, я предполагаю, что Антон имел ввиду, "идеальную" ситуацию, которую 1с собой не представляет, что кстати он неоднократно в разрезе временных файлов и упоминает по ходу настройки. А так всех прогеров 1с сначала учат одному - по любому поводу все кидаем во времянку, поэтому такой перекос.

временные файлы != временные таблицы

Согласен, корректное замечание, обобщаю сознательно.

Тогда от чего деградация производительности?

разные причины могут быть. начните с анализа длительных запросов и оценки показателей ОС (iostat/ram/cpu) во время наблюдаемой деградации

@gsmolk, возможно будет более "юзерфрендли", если при указании момента времени для восстановления, и при отсутствии необходимых вал-ов для его достижения не просто прерывать восстановление, а предупреждать пользователя о том, что вал-ов нет и возможно восстановиться только на такой-то момент, если пользователь согласен, то продолжить .... Ибо такая же ситуация как и с еще "неприехавшими" журналами, возникает когда мы пытаемся восстановиться на момент времени находящийся между двумя РК, журналы между которыми уже удалены по политике хранения

Блин, вот деталей не помню, но вроде когда пг поднимаешь из рк он начинает накатывать логи (до отметки указанной в recovery.conf), а когда не может их получить два пути. А) закончить восстановление и начать обслуживать запросы
Б) упасть, когда запустят попытаться получить из хранилища логи повторно.

recovery_target_action вроде оно

Из логов, которые даёт пг понятно что произошло

Можно же прогнать перед восстановлением валидацию на желаемую точку

В случае неудачи валидация вернёт крайнюю доступную точку

Ну это лишняя операция получается :) в целом ход мысли понятен ...

Ну просто самим восстановлением мы ж не управляем, это уже вотчина постгреса, мы ему только WAL в топку подкидываем

это понятно ... но пбк же знает до какого момента у него есть валы ... и может сразу юзеру сказать, могу дать валы до этой точки, хочешь?

тем более, что по умолчанию перед восстановлением делается валидация ...

Он может это узнать только при валидации

в нашем сценарии у нас большая глубина хранения (до 30 дней) ... но вал-ы я решил хранить на последние 3 копии, ибо при такой глубине в них особого смысла нет, но глубина нужна для расследований по логике прикладных решений. Так вот ранее, когда мы пытались хранить все логи за 30 дней, не возникало проблем восстановиться на любой момент в их границах, сейчас получается требуется лишнее "телодвижение" ...