> > 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