Одна из баз отваливается с такой ошибкой. Думал протестировать, для этого хотел сделать ДТ на всякий случай и проверить в локальной версии - опять падает. Как бороться с таким?

Сам сервиc/служба постгри фурычит? С сервера 1С по Plqsl до постгри достучатся получается?

(1) Другие базы работают нормально. Ща админу позвонил, будем на пару смотреть, но вдруг есть готовое что-то. Отпала только одна база из 5

(1) Служба работает, 9.6 (х64) версия

(2) судя по сообщению сервер 1С не моет подключиться к этой БД. Бэкапы-то есть?

(4) бэкапы делаются ночью. Вопрос в том - перезагрузка сервера поможет (нашел в паре мест в интернете, в том числе на ИС), или надо именно архив восстанавливать? Или еще что может надо сделать? Или мало кто юзает связку Постгре+1С, и нет "коллективных знаний" по этому вопросу?

(5)начни с подключения именно к этой БД средствами plsql. То, что сколько-то баз норм - не показатель про остальные БД.... вариантов море, начиная с того, что базу могли вообще снести, могло место кончиться (если разные БД на разных дисках) и т.п.
Если собираетесь стопать - снимите со всего что снимается копии, как стопнете - сделайте копии каталогов настроек и каталогов с файлами БД прежде чем продолжать эксперименты.

Тут посмотри https://www.linux.org.ru/forum/admin/1934412. Похожая тема и решение.

(0) >>для этого хотел сделать ДТ на всякий случай и проверить в локальной версии - опять падает
Что при этом пишет в логи СУБД, в техжурнал 1С, журналы операционной системы?
Обычно в dt может не выгружаться, когда сервер приложений 1С 32-битный.

(0) давно сталкивался с таким, помню лишь что вылечилось легко, одним параметром в конфиге (каким - не помню)
после lost synchronization with server идет got message type "X", length NNNNN, вот от длины и надо отталкиваться

где-то есть параметр, ограничивающий максимальный кусок данных, нужно найти похожий по размеру
его увеличиваешь раз в 5 сразу, прогоняешь заново

у меня с рабочей машины:
shared_buffers = 8GB
work_mem = 512MB
temp_buffers = 1GB
maintenance_work_mem = 2GB
max_wal_size = 4096MB
effective_cache_size = 24GB

скорее всего один из этих параметров

(9) для какого железа такой конфиг?

(10) 64G мозгов
если у тебя, допустим, 16G - дели все на 4 ;)

work_mem и temp_buffers только и так маленькие, сильно их не обижай
у меня просто 10 баз, и в них ходят все пользователи, в сумме сеансов получается немало, поэтому поставил такими маленькими