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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: fallback_application_name and pgbench
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Streaming replication and a disk full in primary