Re: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name)

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>, 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name)
Date: 2021-08-19 11:08:51
Message-ID: ed1c8ef2-16ac-4e56-d302-b1ff430baeec@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021/08/05 12:18, kuroda(dot)hayato(at)fujitsu(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message kuroda.hayato@fujitsu.com 2021-08-19 11:27:17 RE: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE
Previous Message Ranier Vilela 2021-08-19 11:01:49 Re: Push down time-related SQLValue functions to foreign server