Re: Application name patch - v4 - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: Application name patch - v4
Date
Msg-id e51f66da0912011308o405aa3f9te3ecf7495a05277@mail.gmail.com
Whole thread Raw
In response to Re: Application name patch - v4  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Application name patch - v4  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 12/1/09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Marko Kreen <markokr@gmail.com> writes:
>
> > No, at least both pgbouncer and pgpool consider only (username, database)
>  > pair as pool identifier.  Rest of the startup params are tuned on the fly.
>  > And I think that should stay that way.
>
>
> If you're happy with handling the existing connection parameters in a given
>  way, why would you not want application_name behaving that same way?

Well, in pgbouncer case, the parameters tracked via ParamStatus are
handled transparently.  (client_encoding, datestyle, timezone,
standard_conforming_strings)

Any other parameter is handled via "ignore_startup_parameters" option:
if client supplies random option not appearing there, it is kicked out.

The point being that as pgbouncer cannot handle it transparently, the
admin needs to set the param in postgresql.conf if it is important,
fix the client or let pgbouncer ignore it if client is unfixable.

I have no problem handling appname with latter method, I just wanted
to clarify the target audience for the feature.

-- 
marko


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Block-level CRC checks
Next
From: Tom Lane
Date:
Subject: Re: Application name patch - v4