fallback_application_name and pgbench

Fujii Masao <masao.fujii@gmail.com> wrote:

By default, the application_name of pgbench is "[unknown]". But I think
that pgbench should use fallback_application_name as psql, pg_dump,
etc does. Is it worth creating the patch?

If we will take care of fallback_application_name for contrib modules,
we need to fix not only "pgbench" but also "oid2name" and "dblink".
I think those fixes would be worth; at least for telling third-party
developers to handle the new parameter.

It might be better to set fallback_application_name automatically
in libpq, but it requires argv[0] away from main() function.
GetModuleFilename() is available on Windows for the purpose,
but I don't know what API is available on other platforms.

Regards,
---
Takahiro Itagaki
NTT Open Source Software Center

On Wed, Apr 7, 2010 at 10:21, Takahiro Itagaki
<itagaki.takahiro@oss.ntt.co.jp> wrote:

Fujii Masao <masao.fujii@gmail.com> wrote:

By default, the application_name of pgbench is "[unknown]". But I think
that pgbench should use fallback_application_name as psql, pg_dump,
etc does. Is it worth creating the patch?

If we will take care of fallback_application_name for contrib modules,
we need to fix not only "pgbench" but also "oid2name" and "dblink".
I think those fixes would be worth; at least for telling third-party
developers to handle the new parameter.

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.

It might be better to set fallback_application_name automatically
in libpq, but it requires argv[0] away from main() function.
GetModuleFilename() is available on Windows for the purpose,
but I don't know what API is available on other platforms.

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].

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

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

On Wed, Apr 7, 2010 at 5:30 AM, Dave Page <dpage@pgadmin.org> wrote:

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.

Agreed.

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.

That's true, and I also agree with Magnus's commenet that it's a bad
idea anyway.

...Robert