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

From Shigeru HANADA
Subject Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink
Date
Msg-id 4FEBBA0B.5030102@gmail.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>)
Responses Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink
List pgsql-hackers
On Thu, Jun 14, 2012 at 10:55 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Jun 13, 2012 at 12:07 AM, Amit Kapila <amit.kapila@huawei.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_CONNmacro...
 

Regards,
-- 
Shigeru Hanada


pgsql-hackers by date:

Previous
From: Josh Kupershmidt
Date:
Subject: pg_signal_backend() asymmetry
Next
From: Josh Berkus
Date:
Subject: We probably need autovacuum_max_wraparound_workers