ky0

Почитал комментарии. Если локально 5432 порт работает, а удалённо нет, listen установлен в * - дело не в Постгресе.

Проверять, во что резолвится имя хоста, затем telnet на этот IP с 5432 портом. Затем проверять настройки сети - фаервол, наличие НАТов и т. д.

pgbouncer начал поддерживать prepared statements совсем недавно и в ограниченном объёме. Если есть возможность - лучше от них избавиться.

В целом в вашем случае пулер - то, что нужно. Если приложение не умеет само вовремя отключаться от базы, пусть лучше занимает слоты у pgbouncer.

Принудительно рубить idle коннекты я бы не стал, но в целом это делается вот этим параметром:

client_idle_timeout

Client connections idling longer than this many seconds are closed. This should be larger than the client-side connection lifetime settings, and only used for network problems.

Default: 0.0 (disabled)

Потому что когда на сервере работает несколько сервисов, им нужно явно указывать, сколько памяти они максимально могут потреблять - и в сумме должно получаться меньше, чем есть на сервере (минус сколько-нибудь под процессы ОС). Для Постгреса и вовсе - первая операция после установки, это редактирование настроек памяти.

Альтернатива ковыряния конфигов - разнесение всего хозяйства по контейнерам с лимитами памяти.

Класс ПО, выполняющий подобные функции, называется SCM. Лично я рекомендую Ansible - кажется, что ваша задача на нём реализуется элементарно.

Практически любой современный роутер с USB-портом, если в него воткнуть бокс с диском, умеет его расшаривать в локальную сеть.

Берёте PAM - и долго курите документацию. Именно так решается ваша задача, а не каким-то там парсингом логов.