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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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