Application name patch - v4
in [PgSql]
|
Prev: Backup history file should be replicated in Streaming Replication?
Next: [PATCH] hstore documentation update
From: Robert Haas on 30 Nov 2009 16:38 On Mon, Nov 30, 2009 at 4:11 PM, Dimitri Fontaine <dfontaine(a)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 >> behavior of setting the value in a fashion that would persist across >> resets. I'm not sure that DEFAULT is exactly le mot juste here, but >> agreeing on a keyword would probably be the hardest part of making it >> happen. > > I vaguely remember you explaining how hard it would be to be able to predict the value we RESET to as soon as we add this or that possibility. That's very vague, sorry, but only leaves a bad impression on the keyword choice (bikeshedding, I should open a club). > > So what about SET CONNECTION application_name TO 'whatever'? 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? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dimitri Fontaine on 30 Nov 2009 16:54 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. Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 30 Nov 2009 17:06 On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine <dfontaine(a)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 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? ISTM that the only time you're likely going to use RESET ALL is in a connection pooling environment, and that if you're in a connection pooling environment you probably want to reset the application name along with everything else. I might be wrong, but that's how it seems to me at first blush. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 30 Nov 2009 18:59 Robert Haas wrote: > On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine > <dfontaine(a)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 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? > > ISTM that the only time you're likely going to use RESET ALL is in a > connection pooling environment, and that if you're in a connection > pooling environment you probably want to reset the application name > along with everything else. I might be wrong, but that's how it seems > to me at first blush. Uh, what does it mean to reset the application name? Are you resetting it to what it was before the session started, or to a blank string? -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 30 Nov 2009 19:11
Robert Haas <robertmhaas(a)gmail.com> writes: > On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine > <dfontaine(a)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 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. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |