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 20:07: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:
>  > If the pooler gets new connection with same username:database
>  > as some existing connection, but with different appname,
>  > what it is supposed to do?
> Whatever it wants to.  People seem to be imagining that the appname
>  isn't under the control of the pooler.  It's a connection property,
>  remember?  It won't be set at all unless the pooler explicitly sets it
>  or allows it to be set.
>  I would imagine that typically a pooler would consider the whole
>  connection string as defining connection properties and so appname would
>  work the same as username or anything else, ie, you get shunted into
>  a different connection pool if you ask for a different appname.

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.

Instead, could we make it equal to rest of startup params and track
it's changes via ParamStatus?

That makes it possible for poolers to handle it transparently.
(IOW, you can put several poolers between client and server and
nothing breaks)


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2009-12-01 20:18:31
Subject: Re: Application name patch - v4
Previous:From: Greg StarkDate: 2009-12-01 20:05:53
Subject: Re: Block-level CRC checks

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