Re: Allow escape in application_name

On 2021/09/06 21:28, Fujii Masao wrote:
>
>
> On 2021/09/06 16:48, Masahiro Ikeda wrote:
>> On 2021-09-06 13:21, kuroda(dot)hayato(at)fujitsu(dot)com wrote:
>>> Dear Ikeda-san,
>>>
>>>> I agree that this feature is useful. Thanks for working this.
>>>
>>> Thanks .
>>>
>>>> 1)
>>>>
>>>> Why does postgres_fdw.application_name override the server's option?
>>>>
>>>>> + establishes a connection to a foreign server. This overrides
>>>>> + <varname>application_name</varname> option of the server object.
>>>>> + Note that change of this parameter doesn't affect any existing
>>>>> + connections until they are re-established.
>>>>
>>>> My expected behavior was that application_name option of server object
>>>> overrides the GUC because other GUCs seems behave so. For example,
>>>> log_statement in postgresql.conf can be overrided by ALTER ROLE for
>>>> only specific user. Should the narrower scope setting takes precedence?
>
> An option of a role doesn't always override a GUC setting. For example,
> GUC with PGC_USERSET like work_mem, work_mem setting of a role overrides
> that set in postgresql.conf, as you told. But if work_mem is set by
> SET command, its value overrides the option of a role. So if we should treat
> an option of foreign server object like an option of a role, we should handle
> applicaion_name option for postgres_fdw in that way.
>
> If we want to implement this, we need to check the context of
> postgres_fdw.application_name when using it. If its context is PGC_SIGHUP
> or PGC_POSTMASTER, it needs to be added the connection arrays that
> PQconnectParams() uses before options of server object are processed,
> i.e., application_name of server object overrides the other in this case.
> On the other hand, if its context is higher than PGC_SIGHUP, it needs to
> be added to the arrays after options of server object are processed.
>
> I'm OK with the current proposal for now (i.e., postgres_fdw.application_name
> always overrides that of server object) at least as the first step beucase
> it's simple. But if you want that feature and can simply implement it, I don't
> object to that.

Thanks for explaining.

I forgot to consider about SET command. I understood that SET command should
override the old value, and it's difficult to manage the contexts for server
options and the GUC. Sorry for my impractical proposal.

>> IIUC, we can execute "ALTER SERVERS" commands automatically using scripts?
>> If so, to have finer control seems to be more important than to reduce the
>> effort of
>> overwriting every configuration.
>
> You mean to execute ALTER SERVER automatically via script whenever
> a client connects to the server (i.e., a client passes its application_name
> to the server, the server automatically sets it to the foreign server object,
> then the server uses it as application_name of the remote connection)?

Sorry, Kuroda-san and Fujii-san are right.
If SET command is used, ALTER SERVER doesn't work.

>>>> Is it better to specify that we can use the escaped format
>>>> for application_name option of the server object in the document?
>>>> I think it's new feature too.
>>>
>>> Yeah, I agree. I will add at `Connection Options` section in 0002 patch.
>>> Is it OK? Do we have more good place?
>>
>> +1
>
> +1
>
>>> Actually I did not considering about such a situation...
>>> But I want to choose (1) because the limitation is caused by libpq layer
>>> and the modification is almost unrelated to this patch.
>>> I'm not sure why appname have such a limitation
>>> so at first we should investigate it. How do you think?
>>
>> OK. I agree that (1) is enough for the first step.
>
> +1
>
>> If I have any time, I'll investigate it too.
>
> Maybe we need to consider what happens if different clients use
> application_name with different encodings. How should
> pg_stat_activity.application_name and log_line_prefix, etc handle such case?

Thanks. That makes sense.
I'll check them.

Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION