Re: fallback_application_name and pgbench
От | Dave Page |
---|---|
Тема | Re: fallback_application_name and pgbench |
Дата | |
Msg-id | i2w937d27e11004070230i653498c8vb1f5f30a1b283bb7@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: fallback_application_name and pgbench (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: fallback_application_name and pgbench
|
Список | pgsql-hackers |
On Wed, Apr 7, 2010 at 10:16 AM, Magnus Hagander <magnus@hagander.net> wrote: > Uh, why fallback_application_name? Isn't this the *exact* usecase > where "application_name" should be used? At least for the two apps - > fallback_app_name might be correct for dblink. > > And yes, I think it's a good idea to set it for at least pgbench and oid2name. For pgbench, I can imagine scenarios where you might want to override the name in a script - for example, if you're trying to simulate an environment with multiple workload types running against the same database. > I think that's a pretty bad idea in general. But if we do, then it > should at least never override something that's specified - we need to > keep the ability for tools like psql and pgadmin to set it, regardless > of what they happen to have as argv[0]. We discussed that during the development of the patch - the original idea was to default to argv[0] if no other value was set, but apparently there's no portable way to get at argv[0] from within libpq, even if you ignore Windows. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: