On 2021/09/06 16:48, Masahiro Ikeda wrote:
On 2021-09-06 13:21, kuroda.hay...@fujitsu.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
