Skip site navigation (1) Skip section navigation (2)

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Shigeru HANADA <shigeru(dot)hanada(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink
Date: 2012-06-28 02:16:03
Message-ID: CA+TgmoYEYf2idAeXP-UkJc2XOUiuu7N_hxTPZfseOC=PXJDiEw@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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:
>> On Wed, Jun 13, 2012 at 12:07 AM, Amit Kapila <amit(dot)kapila(at)huawei(dot)com> wrote:
>>> To achieve the same in dblink, we need to parse the passed connection string
>>> and check if it contains fallback_application_name, if yes then its okay,
>>> otherwise we need to append fallback_application_name in connection string.
>>
>> That seems undesirable.  I don't think this is important enough to be
>> worth reparsing the connection string for.  I'd just forget about
>> doing it for dblink if there's no cheaper way.
>
> 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...

*shrug*

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, and
fallback_application_name is only going to apply in cases where the
user doesn't care enough to bother setting application_name.  Let's
not knock ourselves out to solve a problem that may not be that
important to begin with.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-06-28 02:18:22
Subject: Re: We probably need autovacuum_max_wraparound_workers
Previous:From: Josh BerkusDate: 2012-06-28 02:00:11
Subject: We probably need autovacuum_max_wraparound_workers

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group