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

Re: Application name patch - v4

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>
Subject: Re: Application name patch - v4
Date: 2009-12-01 00:26:32
Message-ID: 200912010126.32617.andres@anarazel.de (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tuesday 01 December 2009 01:11:13 Tom Lane 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?
> 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.
Actually I think the poolers make a good case for a SET variant which emulates 
connection set variables...

RESET ALL in a connection pooler does different things than RESET ALL outside 
of one.

Andres

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-12-01 01:02:10
Subject: Re: Block-level CRC checks
Previous:From: Tom LaneDate: 2009-12-01 00:11:13
Subject: Re: Application name patch - v4

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