On 2021/08/05 12:18, kuroda.hayato@fujitsu.com wrote:
> Dear Hackers, Tom,
>
> (I changed subject because this is no longer postgres_fdw's patch)
>
>>> What would be better to think about is how to let users specify this
>>> kind of behavior for themselves. I think it's possible to set
>>> application_name as part of a foreign server's connection options,
>>> but at present the result would only be a constant string. Somebody
>>> who wished the PID to be in there would like to have some sort of
>>> formatting escape, say "%p" for PID. Extrapolating wildly, maybe we
>>> could make all the %-codes known to log_line_prefix available here.
>>
>> I think your argument is better than mine. I will try to implement this approach.
>
> I made a patch based on your advice. I add parse and rewrite function in connectOptions2().
> I implemented in libpq layer, hence any other application can be used.
> Here is an example:
>
> ```
> $ env PGAPPNAME=000%p%utest000 psql -d postgres -c "show application_name"
> application_name
> -----------------------
> 00025632hayatotest000
> (1 row)
> ```
Why did you make even %u and %d available in application_name?
With the patch, they are replaced with the user name to connect as
and the database name to connect to, respectively. Unlike %p
(i.e., PID in *client* side), those information can be easily viewed via
log_line_prefix and pg_stat_activity, etc in the server side.
So I'm not sure how much helpful to expose them also in application_name.
>
>>> I don't think this is a great idea as-is. People who need to do this
>>> sort of thing will all have their own ideas of what they need to track
>>> --- most obviously, it might be appropriate to include the originating
>>> server's name, else you don't know what machine the PID is for.
So some people may want to specify their own ID in application_name
when connecting to the foreign server. For now they can do that by
setting application_name per foreign server object. But this means that
every session connecting to the same foreign server basically should
use the same application_name. If they want to change the setting,
they need to execute "ALTER SERAVER ... OPTIONS ...". Isn't this inconvenient?
If yes, what about allowing us to specify foreign server's application_name
per session? For example, we can add postgres_fdw.application_name GUC,
and then if it's set postgres_fdw always uses it instead of the server-level
option when connecting to the foreign server. Thought?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
