Re: Allow escape in application_name

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?
>
> Hmm... I didn't know the policy in other options, thank you.
> I set higher priority because of the following reason.
> When users set app name as server option and
> create remote connection from same backend process,
> they will use same even if GUC sets.
> In this case users must execute ALTER SERVERS every session,
> and I think it is inconvenient.

Thanks for explaining what you thought. I understood your idea.

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.

But this is just my feeling.
I agree to hear comments from Fujii-san and so on.

> I think both approaches are reasonable, so I also want to ask
> committer.
> Fujii-san, how do you think?
>> 2)
>>
>> 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

I found that '%%' need to be described in the documents
of postgres_fdw.application_name. What do you think?

>> 3)
>>
>> Is the following expected behavior?
>>
>> * 1. [coorinator] configure "postgres_fdw.application_name" as "[%d]".
>> * 2. [coodinator] connect *Non-ASCII* database.
>> * 3. [coodinator] execute queries for remote server.
>> * 4. [remote] execute the following query.
>>
>> ```
>> postgres(2654193)=# SELECT application_name FROM pg_stat_activity
>> WHERE
>> backend_type = 'client backend' ;
>> application_name
>> ---------------------------
>> psql
>> [?????????]
>> ```
>>
>> One of the difference between log_line_prefix and application_name
>> is that whether it only allow clean ASCII chars or not. So, the above
>> behavior is expected.
>>
>> I think there are three choices for handling the above case.
>>
>> 1) Accept the above case because Non-ASCII rarely be used(?), and
>> describe the limitation in the document.
>> 2) Add a new characters for oid of database.
>> 3) Lease the limitation of application_name and make it accept
>> Non-ASCII.
>>
>> As a user, 3) is best for me.
>> But it seems be out of scope this threads, so will you select 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.
If I have any time, I'll investigate it too.

Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION