Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink

From: Robert Haas [mailto:robertmhaas(at)gmail(dot)com]
Sent: Thursday, June 28, 2012 7:46 AM
On Wed, Jun 27, 2012 at 9:57 PM, Shigeru HANADA
<shigeru(dot)hanada(at)gmail(dot)com> wrote:
> On Thu, Jun 14, 2012 at 10:55 PM, Robert Haas <robertmhaas(at)gmail(dot)com>
wrote:
>> Indeed reparsing connection string is not cheap, but dblink does it for
>> checking password requirement for non-in dblink_connstr_check when the
>> local user was not a superuser.  So Amit's idea doesn't seem
>> unreasonable to me, if we can avoid extra PQconninfoParse call.
>>
>> Just an idea, but how about pushing fallback_application_name handling
>> into dblink_connstr_check?  We reparse connection string unless local
>> user was a superuser, so it would not be serious overhead in most cases.
>>  Although it might require changes in DBLINK_GET_CONN macro...

> If it can be done without costing anything meaningful, I don't object,
> but I would humbly suggest that this is not hugely important one way
> or the other. application_name is primarily a monitoring convenience,
> so it's not hugely important to have it set anyway,

In some cases like when DBA does the monitoring in night or sometimes when
he doesn't expect much load on database to do some maintenance tasks,
it can be helpful for him to know if there is any application which he
doesn't expect
to be there. This can be one of the ways he can know the which applications
are currently active.

Users are not bothered to set application_name in general cases as it
doesn't server any
big purpose for them.

I understand this is good to have feature, but if it doesn't cost much then
according to me
it can be done.

With Regards,
Amit Kapila.