стать root-ом, сменить пароль postrges пользователю. но это может повлиять на других, кто помнит старый пароль и активно его использует
другой вариант — NOPASSWD опция в настройках sudo

Как тогда лучше решить задачу «Конкретной роли доступ только к конкретной БД что бы ничего лишнего не было доступно»? Создать свою роль mybaserole которая будет урезана и ее наследовать?

права выдаются так:
- есть пользователи (с точки зрения базы, тоже роли, с возможностью подключения)
- есть объекты в базе
- создаются AccessControlList роли (а-ля mydb_ro, mydb_rw, mydb_dwh, mydb_security), им даются права на конкретные объекты
- создаются роли-групы (а-ля, Support, Operator, Security, Engineer) и им выдаются ACL-права
- роли-группы выдаются конкретным пользователям и определяют их возможности
(я обычно роли-группы пропускаю, слишком сложно.)

Привет! Подскажите, пожалуйста:
1) Как понять кто ходит в Постгрю мимо pgbouncer (есть такое подозрение, исходя их того, что idle  в постгре в разы больше чем в pgbouncer)
2) С чего начать мониторинг постгри (и pgbouncer, если это требуется). Иструмент и метрики какие собирать примерно
Буду очень благодарен за любые ссылки, информацию, ориентацию в пространстве =) -я базами косвенно, но задача появилась и потерялся...
Спасибо.

pg_stat_activity показывает ИП адреса, с которых установлено соединение
по мониторингу сейчас самое модное - графана, к ней есть postgres_exporter, вот неплохая статья:
https://habr.com/ru/post/501696/

подскажите я поменял пароль пользователя в базе, но PgAdmin все равно коннектиться по старому паролю

что подсказать? после смены пароля вы открыли новую сессию?

надо в pg_hba.conf смотреть, может быть там вообще trust выставлен для этого хотса

спасибо огромное

Тоже стараюсь придерживаться это схемы.
Я правильно понимаю что по умолчанию public может видеть все роли, список БД и их схемы?

pg_stat_activity посмотрел - приложение, которое ходит в базу, работает на этом же сервере, т.е. адрес 127.0.0.1 для всех запросов. Можно ли как-то отделить те что пришли от Боунсера, и те что пришли напрямую?

у баунсера с какой-то версии есть опция application_name_add_host, можно включить. также можно попробовать пустить баунсер не через 127.0.0.1, а через unix-socket, или через основной адрес

Мужики подскажьте этих настроек хватает чтоб закрыться от внешних коннекшенов ?

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

Или через 127.0.0.2, например

пароли смогут подбирать при таких настройках, если база слушает мир

слушать мир - это listen_adresses '(не )localhost' ?

То есть задачу «Конкретной роли доступ только к конкретной БД что бы ничего лишнего не было доступно» решить можно, но это может привести к непредвиденным последствиям? Печально 🙁

пробуйте, зачем сразу сдаётесь?..

Попробую, получится, рецепт скину