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

Re: Application name patch - v4

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(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 10:46:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 12/1/09, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Dave Page wrote:
>  > 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).
> If an application can do SET DEFAULT, how does the connection pooler
>  *really* reset the value back to what it was?

By doing SET DEFAULT...

There actually *is* a problem that SET DEFAULT would solve:

1) Pooler creates a connection with one default value.
2) Client creates a connection with another default value (giving param
   in startup pkt)
3) Pooler does SET to apply client's default values.
4) Client does SET to some random value
5) Client does RESET foo/ALL; expecting get default value from 2), instead
   it gets poolers default value from 1).

The inconsistency would be fixed if pooler could do SET DEFAULT in 3).

Note - client doing SET DEFAULT itself would not break anything.
As long we are talking about protocol-tracked parameters...

OTOH, the only app that exhibits the such RESET problem is src/test/regress
so I'm not sure it's worth spending effort to fix this.  Especially
as this open door on app doing SET DEFAULT on non-tracked GUC vars,
which seems to be a much bigger problem.

I don't see how this SET DEFAULT would fix the appname vs. poolers problem
in any way.


In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2009-12-01 11:25:22
Subject: Re: enable-thread-safety defaults?
Previous:From: Jeff DavisDate: 2009-12-01 09:43:30
Subject: Re: New VACUUM FULL

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