Re: Allow escape in application_name

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.

> 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)?

>>> 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?

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION