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: Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Application name patch - v4
Date: 2009-12-01 08:13:58
Message-ID: e51f66da0912010013l11ef65adx43a8ae9c8298f064@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 12/1/09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>  > On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine
>  > <dfontaine(at)hi-media(dot)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's a 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

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2009-12-01 08:47:24
Subject: Re: Block-level CRC checks
Previous:From: Heikki LinnakangasDate: 2009-12-01 08:04:07
Subject: Re: Block-level CRC checks

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