Application name patch - v4
in [PgSql]
|
Prev: Backup history file should be replicated in Streaming Replication?
Next: [PATCH] hstore documentation update
From: Tom Lane on 1 Dec 2009 11:19 Dave Page <dpage(a)pgadmin.org> writes: > On Tue, Dec 1, 2009 at 9:16 AM, Heikki Linnakangas > <heikki.linnakangas(a)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 :-). As the alternative would > involve bumping the fe-be protocol version, it seems like a reasonable > approach to me. 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 app name. The main disadvantage would be that you'd get a double connection attempt == more overhead anytime you use an 8.5+ libpq to connect to 8.4- server. People never complained that hard about the similar double connection attempt when 7.4+ libpq connected to 7.3- servers, so maybe we should just go that way. 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
From: Dave Page on 1 Dec 2009 11:23 On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane <tgl(a)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 app name. The main disadvantage would > be that you'd get a double connection attempt == more overhead > anytime you use an 8.5+ libpq to connect to 8.4- server. People > never complained that hard about the similar double connection attempt > when 7.4+ libpq connected to 7.3- servers, so maybe we should just > go that way. I looked (briefly) at doing that when we first ran into this suggestion. As you pointed out at the time, it seemed like that would require some fairly ugly hackery in fe-connect.c -- 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: Tom Lane on 1 Dec 2009 11:28 Dave Page <dpage(a)pgadmin.org> writes: > On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane <tgl(a)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 app name. > I looked (briefly) at doing that when we first ran into this > suggestion. As you pointed out at the time, it seemed like that would > require some fairly ugly hackery in fe-connect.c Perhaps, but at the time it wasn't apparent that issuing a separate SET would create user-visible behavioral inconsistencies. Now that we've realized that, I think we should reconsider. If people are agreed that double connect is a better alternative I'm willing to go look at how to make it happen. 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
From: Dave Page on 1 Dec 2009 11:33 On Tue, Dec 1, 2009 at 4:28 PM, Tom Lane <tgl(a)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 look at how to make it happen. That's good, 'cos I'm sure it'll end up being a whole lot less ugly than if I did it :-) -- 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: Marko Kreen on 1 Dec 2009 11:52
On 12/1/09, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Dave Page <dpage(a)pgadmin.org> writes: > > On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane <tgl(a)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 app name. > > > > I looked (briefly) at doing that when we first ran into this > > suggestion. As you pointed out at the time, it seemed like that would > > require some fairly ugly hackery in fe-connect.c > > > Perhaps, but at the time it wasn't apparent that issuing a separate SET > would create user-visible behavioral inconsistencies. Now that we've > realized that, I think we should reconsider. > > If people are agreed that double connect is a better alternative > I'm willing to go look at how to make it happen. Is it supposed to work with pooling or not? If the pooler gets new connection with same username:database as some existing connection, but with different appname, what it is supposed to do? -- 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 |