Re: JDBC gripe list
От | Marc Mamin |
---|---|
Тема | Re: JDBC gripe list |
Дата | |
Msg-id | C4DAC901169B624F933534A26ED7DF31034BBB6E@JENMAIL01.ad.intershop.net обсуждение исходный текст |
Ответ на | Re: JDBC gripe list (Achilleas Mantzios <achill@matrix.gatewaynet.com>) |
Ответы |
Re: JDBC gripe list
|
Список | pgsql-jdbc |
> > Achilleas Mantzios, 31.03.2011 09:58: > > >> If you are on 9.0 and have control over the connection > > >> initialization in the pool, then using 9.0's "application_name" > > >> might be a solution to this. > > >> > > >> If you can configure the pool to run > > >> > > >> SET application_name = 'app_user_name' > > >> > > >> when a connection is taken out of the pool, then this name can be > > >> part of the log message in the PostgreSQL logfile. > > >> > > > > > > Yes, sure, thanx for sharing this. One could indeed do this by > > > hacking/subclassing the relevant pool classes in the app server. But > > > that would still be a work around. I dont know why SET application > > > ='' is reflected in the log files, but SET ROLE is not. Is it > > > intentional ? Anyways this question should be targeted to the backend > > > guys rather than here. > > > > The actual SET application_name is not logged directly, but you can change the log configuration to include the namethat is set with that statement. > > > > You mean log_line_prefix parameter. Ok but a > log_line_prefix = '%d %a %u %p %c %m ' > while it prints correctly %a (application) (as set by SET application_name), > it does not print correctly %u (user) (as set by SET ROLE). Hello, I would not say that %u return an incorrect user as the info stay relevant after changing the connection role, but an additional parameter to log the current role would be indeed interesting. regards, Marc Mamin
В списке pgsql-jdbc по дате отправления: