From: | Shigeru HANADA <shigeru(dot)hanada(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(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 01:57:31 |
Message-ID: | 4FEBBA0B.5030102@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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...
Regards,
--
Shigeru Hanada
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2012-06-28 02:00:11 | We probably need autovacuum_max_wraparound_workers |
Previous Message | Josh Kupershmidt | 2012-06-28 00:38:24 | pg_signal_backend() asymmetry |