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: Dave Page <dpage(at)pgadmin(dot)org>, 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>
Subject: Re: Application name patch - v4
Date: 2009-12-01 09:11:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tuesday 01 December 2009 09:59:17 Dave Page wrote:
> On Tue, Dec 1, 2009 at 12:26 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > 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.
> Eh? Not sure I follow that, but then I haven't had a coffee yet.
Well. RESET ALL in a pooler sets values to the initial connection values the 
pooler had, not the ones of pooled connection.

On the same time there are multiple people complaining about such default 
values being contraproductive to pooling environments because they reset to 
the wrong values.
I dont really get that argument - the pooler should just issue a SET 
CONNECTION DEFAULT for all connection values. That would make it far more 
transparent than before...

> Upthread, Tom suggested a new 'SET DEFAULT ...' variant of SET which
> could be used to set the default GUC value that RESET would revert to.
> This seems to me to be the ideal solution, and I'd somewhat hesitantly
> volunteer to work on it (hesitantly as it means touching the parser
> and other areas of the code I currently have no experience of).
As I had initially suggested something like that I agree here.


In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2009-12-01 09:16:45
Subject: Re: Application name patch - v4
Previous:From: Dave PageDate: 2009-12-01 08:59:17
Subject: Re: Application name patch - v4

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