Re: fallback_application_name and pgbench - Mailing list pgsql-hackers

From Robert Haas
Subject Re: fallback_application_name and pgbench
Date
Msg-id j2o603c8f071004070505rc6dd5edaxa5a3e2a64afda676@mail.gmail.com
Whole thread Raw
In response to Re: fallback_application_name and pgbench  (Dave Page <dpage@pgadmin.org>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Remaining Streaming Replication Open Items
Next
From: Simon Riggs
Date:
Subject: Re: Remaining Streaming Replication Open Items