1. Установите исследуемый сеанс
Закрепите экземпляр, базу, время, приложение и конкретное соединение. Разбор относится к PostgreSQL 18. Не начинайте атрибуцию человека с одного имени DB-role: приложение может пользоваться общей ролью и пулом. Если расследуется прошлый запрос, сначала сохраните его серверный и прикладной контекст.
2. Снимите текущую identity чтением
SELECT session_user, current_user возвращает значения только того сеанса, в котором выполняется запрос. Он не спрашивает сервер, кто работал в чужом backend вчера. Выполненный администратором из другого подключения результат не подставляется в старое событие. В журнале расследования пометьте время снимка и принадлежность соединения.
3. Разберите авторскую иллюстрацию
В заметке session_user=demo_pool и current_user=demo_read иллюстрируют различие роли сеанса и контекста исполнения. Это не доказанный результат конкретного механизма переключения. Поле application_user добавлено автором заметки как требуемое внешнее свидетельство и не является стандартной колонкой PostgreSQL. Имя demo_read не говорит о том, какие права действительно действовали для исследуемого объекта.
4. Проверьте границы ролей
В PostgreSQL current_user используется при проверках полномочий и может отличаться от исходной роли, в том числе из-за SET ROLE или SECURITY DEFINER. Возможны и изменения session authorization при соответствующих правах. Поэтому одинаковая пара имён не гарантирует отсутствие других контекстов, а различная пара не устанавливает единственную причину. Сопоставляйте значения с фактическим statement и конфигурацией приложения.
5. Дойдите до прикладного пользователя
Свяжите backend/session с запросом приложения по существующим идентификаторам и времени. Проверьте авторизацию приложения, запись операции и владельца задания автоматизации. Если пул обслуживает разных пользователей одной DB-role, нужен этот отдельный слой. При анализе выданных прав дополнительно используйте аудит изменений роли, отличая инициатора команды от получателя привилегии и от человека за сервисной учётной записью.
6. Если человека установить нельзя
Запишите, какие части цепочки отсутствуют: сквозной request ID, история пула, серверный аудит или прикладная аутентификация. Не заменяйте их адресом клиента, именем application_name либо текущей ролью нового соединения. Итог может достоверно ограничиться технической DB-identity. Это содержательный результат с границей, а не основание выдумывать персональную атрибуцию.