Re: Application name patch - v4

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Subject: Re: Application name patch - v4
Date: 2009-12-01 21:08:06
Message-ID: e51f66da0912011308o405aa3f9te3ecf7495a05277@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/1/09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marko Kreen <markokr(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-01 21:20:12 Re: Application name patch - v4
Previous Message Andrew Dunstan 2009-12-01 20:58:44 Re: Block-level CRC checks