Application name patch - v4
in [PgSql]
|
Prev: Backup history file should be replicated in Streaming Replication?
Next: [PATCH] hstore documentation update
From: Dave Page on 1 Dec 2009 04:18 On Tue, Dec 1, 2009 at 9:16 AM, Heikki Linnakangas <heikki.linnakangas(a)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 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? There has to be some level of trust here :-). As the alternative would involve bumping the fe-be protocol version, it seems like a reasonable approach to me. -- 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:22 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 > > 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? Why does it need to? SET DEFAULT should imho only be allowed for values whcih can be set during connection initiation. For those it can simply issue the sets anyway. 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: Tatsuo Ishii on 1 Dec 2009 04:30 > 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. +1. Connection poolers shoud be transparent to the clients. If some connection poolers want to behavior differently, then probably they would be better to be called "TP monitor" or some such. TP monitor has its own API and it is at liberty behave what it wants. Don't get me wrong. I would not say TP monitor is useless, rather it has very usefull use cases I think. However, pushing its semantics about sessions to PostgreSQL side, would be counterproductive for both TP monitor and PostgreSQL. -- Tatsuo Ishii SRA OSS, Inc. Japan -- 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 05:46 On 12/1/09, Heikki Linnakangas <heikki.linnakangas(a)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 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. -- 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: Brar Piening on 1 Dec 2009 06:54
On Tue, 1 Dec 2009 09:59:17 +0100, Dave Page <dpage(a)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 at connection time cannot be reset, so allowing that > for application name does seem like a POLA violation. > I'd like to support this Argument. As I understand this patch from http://archives.postgresql.org/pgsql-hackers/2009-10/msg00711.php it is intended to support some kind of feature like the SQL Server "...;Application Name=MyApp;..." connection string value, making the name of the user level (or whatever) application name available at the Database/SQL level. I don't know about pgpool but as far as I know, some client side connection pooling implementations use one pool per connection string/url (.Net Data Providers, JDBC). They would probably want set the application_name in the startup message and will expect it to fall back to this value when calling RESET ALL (or what ever you like to be the command to go back to the values that were requested on connection startup) on recycling a connection from the pool. Any other solution would greatly complicate recycling of connections for per connection string pooling szenarios. Regards, Brar -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |