Re: Client application name
От | Dave Page |
---|---|
Тема | Re: Client application name |
Дата | |
Msg-id | 937d27e10910210245q5bdce226xc2590e7b1751ced@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Client application name (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Client application name
|
Список | pgsql-hackers |
On Wed, Oct 21, 2009 at 10:40 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Wed, 2009-10-21 at 10:19 +0100, Dave Page wrote: >> On Wed, Oct 21, 2009 at 10:14 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> >> > ISTM much of the complexity discussed relates to this second feature. >> > Let's just concentrate on getting the connection-pool-identification >> > aspect of this done right and then maybe add second part later. >> >> That side of the patch works fine already (it's only a GUC after all), >> as does the during-connection option. The current problem is that old >> servers will barf if it's set in the startup packet. >> >> And yes, the stats part also works :-). > > Then I say this feature is good to go. It's much needed. Well done. Thanks. > Strip out the during-connection option for now. Let the startup packet > stuff come later, if ever. Either way there's a little work to do - if we forget about the startup packet (which I'd rather not do - I can see the value in having the app name in the connection log messages), I'll still need to tweak things such that libpq can set the GUC post-connection, either using the code Tom mentioned yesterday, or just issuing an explicit SET. I don't see that being a problem though. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com PGDay.EU 2009 Conference: http://2009.pgday.eu/start
В списке pgsql-hackers по дате отправления: