2009/12/2 Tom Lane t...@sss.pgh.pa.us:
Dave Page dp...@pgadmin.org writes:
On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think that we need to bump the protocol version. The real
alternative here would be that libpq sends a startup packet that
includes
On Wed, Dec 2, 2009 at 8:14 AM, Magnus Hagander mag...@hagander.net wrote:
If we patch the back branches like that, anyone who's annoyed by the
extra connection cycle just has to update to latest minor release
of their server to make it work more smoothly. Comments?
Magnus Hagander mag...@hagander.net writes:
2009/12/2 Tom Lane t...@sss.pgh.pa.us:
BTW, it strikes me that it would only be a matter of a couple of lines
to persuade older servers to ignore application_name in the startup
packet, instead of throwing a tantrum. Obviously we must make libpq
On 12/1/09, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine
dfonta...@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
On Tue, Dec 1, 2009 at 12:26 AM, Andres Freund and...@anarazel.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
On Tuesday 01 December 2009 09:59:17 Dave Page wrote:
On Tue, Dec 1, 2009 at 12:26 AM, Andres Freund and...@anarazel.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
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
On Tue, Dec 1, 2009 at 9:16 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.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,
On Tuesday 01 December 2009 10:16:45 Heikki Linnakangas 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
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
On 12/1/09, Heikki Linnakangas heikki.linnakan...@enterprisedb.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
On Tue, 1 Dec 2009 09:59:17 +0100, Dave Page dp...@pgadmin.org wrote:
I do see the argument that RESET ALL should revert user changes to
application_name though, but I maintain they should reset to the value
set at connection time, not to null. As has been pointed out already,
other values set
Dave Page dp...@pgadmin.org writes:
On Tue, Dec 1, 2009 at 9:16 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If an application can do SET DEFAULT, how does the connection pooler
*really* reset the value back to what it was?
There has to be some level of trust here :-).
On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think that we need to bump the protocol version. The real
alternative here would be that libpq sends a startup packet that
includes application_name, and if it gets an error back from that,
it starts over without the
Dave Page dp...@pgadmin.org writes:
On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think that we need to bump the protocol version. The real
alternative here would be that libpq sends a startup packet that
includes application_name, and if it gets an error back
On Tue, Dec 1, 2009 at 4:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If people are agreed that double connect is a better alternative
I still kinda like 'SET DEFAULT', but I'm far from wed to it. A double
connect certainly seems like it would be better than the
inconsistency.
I'm willing to go
On 12/1/09, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think that we need to bump the protocol version. The real
alternative here would be that libpq sends a startup packet that
Marko Kreen mark...@gmail.com writes:
If the pooler gets new connection with same username:database
as some existing connection, but with different appname,
what it is supposed to do?
Whatever it wants to. People seem to be imagining that the appname
isn't under the control of the pooler.
On 12/1/09, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
If the pooler gets new connection with same username:database
as some existing connection, but with different appname,
what it is supposed to do?
Whatever it wants to. People seem to be imagining
Marko Kreen mark...@gmail.com writes:
No, at least both pgbouncer and pgpool consider only (username, database)
pair as pool identifier. Rest of the startup params are tuned on the fly.
And I think that should stay that way.
If you're happy with handling the existing connection parameters in
On 12/1/09, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
No, at least both pgbouncer and pgpool consider only (username, database)
pair as pool identifier. Rest of the startup params are tuned on the fly.
And I think that should stay that way.
If you're
Marko Kreen mark...@gmail.com writes:
On 12/1/09, Tom Lane t...@sss.pgh.pa.us wrote:
If you're happy with handling the existing connection parameters in a given
way, why would you not want application_name behaving that same way?
Well, in pgbouncer case, the parameters tracked via ParamStatus
On 12/1/09, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
On 12/1/09, Tom Lane t...@sss.pgh.pa.us wrote:
If you're happy with handling the existing connection parameters in a given
way, why would you not want application_name behaving that same way?
Well,
Dave Page dp...@pgadmin.org writes:
On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think that we need to bump the protocol version. The real
alternative here would be that libpq sends a startup packet that
includes application_name, and if it gets an error back
Le 30 nov. 2009 à 00:25, Tom Lane a écrit :
The thing is that the libpq API treats application_name as a *property
of the connection*.
Oh. Yeah.
We could add a third keyword, say SET DEFAULT, that would have the
behavior of setting the value in a fashion that would persist across
resets.
On Mon, Nov 30, 2009 at 4:11 PM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Le 30 nov. 2009 à 00:25, Tom Lane a écrit :
The thing is that the libpq API treats application_name as a *property
of the connection*.
Oh. Yeah.
We could add a third keyword, say SET DEFAULT, that would have the
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
On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine
dfonta...@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
Robert Haas wrote:
On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine
dfonta...@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
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine
dfonta...@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
On Tuesday 01 December 2009 01:11:13 Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine
dfonta...@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
On Sat, Nov 28, 2009 at 11:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dave Page dp...@pgadmin.org writes:
Updated application name patch, including a GUC assign hook to clean
the application name of any unsafe characters, per discussion.
Applied with assorted editorialization. There were a
Dave Page dp...@pgadmin.org writes:
On Sat, Nov 28, 2009 at 11:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
1. The patch prevents non-superusers from seeing other users'
application names in pg_stat_activity. This seems at best pretty
debatable to me. Yes, it supports usages in which you want
Hi,
Le 29 nov. 2009 à 18:22, Tom Lane a écrit :
I think we should use GUC_NO_RESET_ALL.
I agree with you, but it seems we have at least as many votes to not do
that. Any other votes out there?
Driven by the pooler use case (pgbouncer, even), I'd say RESET ALL should reset
also the
Dimitri Fontaine dfonta...@hi-media.com writes:
Le 29 nov. 2009 à 18:22, Tom Lane a écrit :
I think we should use GUC_NO_RESET_ALL.
I agree with you, but it seems we have at least as many votes to not do
that. Any other votes out there?
Driven by the pooler use case (pgbouncer, even), I'd
Tom Lane wrote:
: One possibility would be to make it possible to issue SETs that
behave : as if set in a startup packet - imho its an implementation
detail that : SET currently is used.
I think there's a good deal of merit in this, and it would't be hard
at all to implement, seeing that we
Fujii Masao masao.fu...@gmail.com writes:
Why doesn't application_name appear in postgresql.conf.sample?
That is expected to be set from only libpq?
It would seem pretty silly to set it in the conf file. You *can*,
if you want, but I see no reason to list it there.
On Mon, Nov 30, 2009 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
Why doesn't application_name appear in postgresql.conf.sample?
That is expected to be set from only libpq?
It would seem pretty silly to set it in the conf file. You *can*,
if you
On Mon, Nov 30, 2009 at 11:21 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Nov 30, 2009 at 10:20 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
Why doesn't application_name appear in postgresql.conf.sample?
That is expected to be set from only libpq?
Hi,
On Monday 30 November 2009 01:16:43 Florian G. Pflug wrote:
Tom Lane wrote:
: One possibility would be to make it possible to issue SETs that
behave : as if set in a startup packet - imho its an implementation
detail that : SET currently is used.
I think there's a good deal of
Dave Page dp...@pgadmin.org writes:
Updated application name patch, including a GUC assign hook to clean
the application name of any unsafe characters, per discussion.
Applied with assorted editorialization. There were a couple of
definitional issues that I don't recall if we had consensus on:
On Sat, Nov 28, 2009 at 06:47:49PM -0500, Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
Updated application name patch, including a GUC assign hook to clean
the application name of any unsafe characters, per discussion.
Applied with assorted editorialization. There were a couple of
On Sunday 29 November 2009 00:47:49 Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
Updated application name patch, including a GUC assign hook to clean
the application name of any unsafe characters, per discussion.
Applied with assorted editorialization. There were a couple of
On Sat, Nov 28, 2009 at 7:27 PM, Joshua Tolley eggyk...@gmail.com wrote:
On Sat, Nov 28, 2009 at 06:47:49PM -0500, Tom Lane wrote:
Dave Page dp...@pgadmin.org writes:
Updated application name patch, including a GUC assign hook to clean
the application name of any unsafe characters, per
44 matches
Mail list logo
