Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink
Date
Msg-id 003201cd54f6$29f4a7c0$7dddf740$@kapila@huawei.com
Whole thread Raw
In response to Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
From: Robert Haas [mailto:robertmhaas@gmail.com]
Sent: Thursday, June 28, 2012 7:46 AM
On Wed, Jun 27, 2012 at 9:57 PM, Shigeru HANADA
<shigeru.hanada@gmail.com> wrote:
> On Thu, Jun 14, 2012 at 10:55 PM, Robert Haas <robertmhaas@gmail.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.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: We probably need autovacuum_max_wraparound_workers
Next
From: Simon Riggs
Date:
Subject: Re: Uh, I change my mind about commit_delay + commit_siblings (sort of)