Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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,

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.


In response to


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group