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