Re: Application name patch - v4 - Mailing list pgsql-hackers

On 12/1/09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>  > On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine
>  > <dfontaine@hi-media.com> wrote:
>  >> Le 30 nov. 2009 à 22:38, Robert Haas a écrit :
>  >>> I still don't really understand why we wouldn't want RESET ALL to
>  >>> reset the application name.  In what circumstances would you want the
>  >>> application name to stay the same across a RESET ALL?
>  >>
>  >> I can't see any use case, but SET/RESET is tied to SESSION whereas application_name is a CONNECTION property. So
it'sa hard sell that reseting the session will change connection properties. 
>
>  > Is there any technical difference between a connection property and a
>  > session property?  If so, what is it?
>
>
> 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.

+1

This SESSION/CONNECITION terminology is confusing, better would be
talk about client connection/session (client->pooler) and server
connection/session (pooler->server) if you are talking about pooling.

>  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.
>
>  The only reason we're even having this discussion is that libpq
>  isn't able to make application_name work exactly like its other
>  connection parameters because of the backwards-compatibility issue.
>  Maybe we should think a bit harder about that.  Or else give up
>  having libpq manage it like a connection parameter.

Making it work in session pooling mode (pgpool) is easy - RESET ALL
and SET needs to work.

The question is whether it should work also in transaction
pooling mode (pgbouncer / JDBC).  I see 2 variants:

1. Clients are allowed to specify it only in startup packet.  But, uh, poolers can set it also in the middle of
session.

2. Make it into protocol-tracked variable.

The 1) seems inconsistent and backwards-incompatible - client does
not know server version yet and old servers dont accept it.

I don't see problems with 2).

Or we could decide it is not meant for transaction pooling environments.

--
marko