Доброго времени суток!

Имеется продакшн сервер, на котором надо помониторить что за запросы гоняются, запросы то так понятно, но там параметры, которые не увидеть в pg_stat_activity.query, максимум часть и то без параметров, только ?

Есть вариант
alter system set log_statement TO 'all';
select pg_reload_conf();
но тогда будет в лог сыпаться оооооочень много лишнего, что крайне не желательно.

Есть вариант
alter role service_user set log_statement TO 'all';
тут лучше, но надо заставлять сервис переподключаться или снова в базу "войти" только тогда именно от этого юзера будет сыпать в лог. Ну чтобы выключить - примерно то же самое надо сделать.

Та же ситуация с
alter database service_db set log_statement TO 'all';

Вот решил поискать в документации, но не нашел, может плохо смотрел. Может есть какой способ нагруженный сервис не отрубать, а перечитать типа как select pg_reload_conf() на лету? Ну а потом так же на лету на DEFAULT сбросить, чтобы посмотрев все вернуть на свои места.

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

Павел Лузанов,

отправил kill -HUP тому процессу, что подключен к серверу БД, но не перечиталось, к сожалению. Ubuntu 18.04

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

Alexius, pid брал именно из pg_stat_activity

как то такpostgres=# select pid from pg_stat_activity where usename = 'makpol';
pid
-------
26698
(1 строка)

postgres=# \! kill -HUP 26698
postgres=# \q
postgres@STest:~$ выход
root@STest:~# kill -HUP 26698

Видимо без убийства процесса никак :(

Пробовал также и
/usr/lib/postgresql/11/bin/pg_ctl kill HUP 26698
но также эффекта 0

понять бы, если без реконнекта и не на весь кластер применять нельзя, то может разработка реализует
много для чего это бы помогло ИМХО
ну минимум гибкость в конфигурации

Alexius, да если alter system сделать то все ок, и перезаходить не надо и pg_reload_conf() то же самое делает (KILL -HUP)
Я именно про конфиг на уровне базы или роли,

в начале топика зря не выделил
вотЕсть вариант
alter system set log_statement TO 'all';
select pg_reload_conf();
но тогда будет в лог сыпаться оооооочень много лишнего, что крайне не желательно.

В том то и фишка, что сделать
alter role service_user set log_statement TO 'all';
или
alter database service_db set log_statement TO 'all';
но....
Надо применить на лету, так же как и alter system
Но, вот перечитывает когда - применяет настройки с системы, но не заменяет их настройками с базы, а если есть на роли то и потом еще настройками роли.

Вот в этом то и вопрос.

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

alter system и select pg_reload_conf(), который и посылает SIGHUP юзаю, но тут немного другой случай.

Вот не знаю где попробовать найти ответ, может постгресПрофессиональный что подскажут, как то помогали по партициям

Мало того, я вот еще что заметил...
Проверяю не в одной сессии, а в разных и на разных серверах, чтобы ближе быть к реальному случаю.

На одном сервере я под postgres а на другом под юзером сервиса в базе сервиса, но чтобы понятнее последовательность было то там где я postgres будет =#, а там где юзер сервиса будет =>, ну собственно как в родном psql :)

Для начала мы на исходной и у нас все взято из файлов конфигурации и значения что у роли что у базы что у системы DEFAULT
Ну и для надежности делаем базе системе и роли сброс и на клиенте переконнектимся, в логе увидим также что все применилось
сброс к DEFAULTalter system set log_statement TO DEFAULT;
select pg_reload_conf();
alter database service_db set log_statement TO DEFAULT;
alter role service_user set log_statement TO DEFAULT;
------------------на клиенте-----------------------------------
service_db=> \c
Вы подключены к базе данных "service_db" как пользователь "service_user".
service_db=> show log_statement;
log_statement
---------------
none

Ну и делаем самое простое, то что работает (когда у нас нет ничего из параметров заданного в database или role)
делай разpostgres=# show log_statement;
log_statement
---------------
none

postgres=# alter system set log_statement TO 'ddl';
ALTER SYSTEM
postgres=# select pg_reload_conf();
pg_reload_conf
----------------
t

postgres=# show log_statement;
log_statement
---------------
ddl
(1 строка)

----------------------------------------------------------
2018-12-20 08:38:45.250 MSK [1630] СООБЩЕНИЕ: получен SIGHUP, файлы конфигурации перезагружаются
2018-12-20 08:38:45.251 MSK [1630] СООБЩЕНИЕ: параметр "log_statement" принял значение "ddl"
----------------------------------------------------------
service_db=> show log_statement;
log_statement
---------------
none

service_db=> show log_statement;
log_statement
---------------
ddl


Тут все работает, менять можно сколько угодно раз и все перечитается и применится, но.... когда активность большая в лог такое летит, что забивается быстро, да и доп нагрузка появляется, ну и неправильно это, но да, так работает. Можно упражняться в grep-ании. Я тут для удобства поставил ddl но можно и all и так далее....
Следующий эксперимент постом ниже =>

Идем дальше, пусть у нас на уровне базы и роли log_statement - none и по сути он взят из файлов конфигурации
Далее берем и назначаем, пусть на уровне базы
делай дваpostgres=# alter database service_db set log_statement TO 'ddl';
ALTER DATABASE
postgres=# \! kill -HUP 32641
------------в это время у клиента-----
service_db => select pg_backend_pid();
32641

service_db => show log_statement;
none

service_db => \c
Вы подключены к базе данных "service_db " как пользователь "service_user".
service_db => show log_statement;
ddl
Т.е. хоть обSIGHUP-ся фиг применит то чт она уровне базы было. Пока не переподключишься, по сути новый процесс не создашь, но...
Ну фиг с ним, тогда возьмем и на уровне SYSTEM поменяем
далееpostgres=# alter system set log_statement TO 'all';
ALTER SYSTEM
postgres=# show log_statement;
none

postgres=# select pg_reload_conf();
t

postgres=# show log_statement;
all

postgres=# \! kill -HUP 32653
------------в это время у клиента-----
service_db => show log_statement;
none

service_db => \c
Вы подключены к базе данных "service_db " как пользователь "service_user".
service_db => show log_statement;
ddl

service_db => show log_statement;
ddl

service_db => select pg_backend_pid();
32653

service_db => show log_statement;
ddl

Alexius, да, это выход, делать так, потом только не забыть сбросить, а то как после рестарта перечитается.... :) Ну а тут же про сервис вопрос возникает, получается да, на уровне SYSTEM я задаю, ищу все процессы им SIGHUP и пока они не переподключились - все ок, как только переподключились - ничего не перечитают, но это обходить одновременным ALTER DATABASE, но помнить, что если есть на уровне DATABASE то не применится ничего с SYSTEM, хоть обSIGHUPся....
Бывают костыли, а бывают неучтенные особенности, а может просто не документированно как в таких ситуациях правильнее быть?

Еще надеюсь, что есть более правильный путь. Может кто писал разрабам? Ну не редкая ситуация с применением настроек же....