Re: [HACKERS] fallback_application_name and pgbench
Fujii Masao masao.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] fallback_application_name and pgbench
On Wed, Apr 7, 2010 at 10:21, Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp wrote: Fujii Masao masao.fu...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] fallback_application_name and pgbench
On Wed, Apr 7, 2010 at 10:16 AM, Magnus Hagander mag...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] fallback_application_name and pgbench
On Wed, Apr 7, 2010 at 5:30 AM, Dave Page dp...@pgadmin.org wrote: On Wed, Apr 7, 2010 at 10:16 AM, Magnus Hagander mag...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] fallback_application_name and pgbench
Hi, 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? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
