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

Re: Application name patch - v4

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: robertmhaas(at)gmail(dot)com, dfontaine(at)hi-media(dot)com, dpage(at)pgadmin(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Application name patch - v4
Date: 2009-12-01 09:30:03
Message-ID: 20091201.183003.32171609.t-ishii@sraoss.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
> The point is that every other thing you can set in a libpq connection
> string is persistent throughout the connection.  For the ones that you
> can change at all, such as client_encoding, *RESET ALL actually resets
> it to what was specified in the connection string*.  It does not satisfy
> the POLA for application_name to behave differently.
> 
> I think the argument about poolers expecting something different is
> hogwash.  A pooler would want RESET ALL to revert the connection state
> to what it was at establishment.  That would include whatever
> application name the pooler would have specified when it started the
> connection, I should think.

+1. Connection poolers shoud be transparent to the clients.

If some connection poolers want to behavior differently, then probably
they would be better to be called "TP monitor" or some such. TP
monitor has its own API and it is at liberty behave what it
wants. Don't get me wrong. I would not say TP monitor is useless,
rather it has very usefull use cases I think. However, pushing its
semantics about sessions to PostgreSQL side, would be
counterproductive for both TP monitor and PostgreSQL.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

In response to

pgsql-hackers by date

Next:From: Jeff DavisDate: 2009-12-01 09:43:30
Subject: Re: New VACUUM FULL
Previous:From: Andres FreundDate: 2009-12-01 09:22:13
Subject: Re: Application name patch - v4

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