Application name patch - v4
in [PgSql]
|
Prev: Backup history file should be replicated in Streaming Replication?
Next: [PATCH] hstore documentation update
From: Andres Freund on 30 Nov 2009 19:26 On Tuesday 01 December 2009 01:11:13 Tom Lane wrote: > 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? > 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 -- 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: Marko Kreen on 1 Dec 2009 03:13 On 12/1/09, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > 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. +1 This SESSION/CONNECITION terminology is confusing, better would be talk about client connection/session (client->pooler) and server connection/session (pooler->server) if you are talking about pooling. > 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. Making it work in session pooling mode (pgpool) is easy - RESET ALL and SET needs to work. The question is whether it should work also in transaction pooling mode (pgbouncer / JDBC). I see 2 variants: 1. Clients are allowed to specify it only in startup packet. But, uh, poolers can set it also in the middle of session. 2. Make it into protocol-tracked variable. The 1) seems inconsistent and backwards-incompatible - client does not know server version yet and old servers dont accept it. I don't see problems with 2). Or we could decide it is not meant for transaction pooling environments. -- marko -- 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: Dave Page on 1 Dec 2009 03:59 On Tue, Dec 1, 2009 at 12:26 AM, Andres Freund <andres(a)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 that, but then I haven't had a coffee yet. 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 at connection time cannot be reset, so allowing that for application name does seem like a POLA violation. 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). -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- 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: Andres Freund on 1 Dec 2009 04:11 On Tuesday 01 December 2009 09:59:17 Dave Page wrote: > On Tue, Dec 1, 2009 at 12:26 AM, Andres Freund <andres(a)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 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. Andres -- 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: Heikki Linnakangas on 1 Dec 2009 04:16
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? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |