Re: [postgres_fdw] add local pid to fallback_application_name

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [postgres_fdw] add local pid to fallback_application_name
Date: 2021-07-29 15:06:41
Message-ID: 714523.1627571201@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"kuroda(dot)hayato(at)fujitsu(dot)com" <kuroda(dot)hayato(at)fujitsu(dot)com> writes:
> I propose adding trackable information in postgres_fdw, in order to track remote query correctly.

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 I think most people with this sort of requirement will be overriding
the default application name anyway, so we might as well keep the
default behavior simple.

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.

Perhaps this is overkill. But I think the patch you have here is
not going to make very many people happy: it'll either be detail
they don't want, or too little detail.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2021-07-29 15:10:17 Re: pg_upgrade does not upgrade pg_stat_statements properly
Previous Message Dave Cramer 2021-07-29 15:01:43 Re: pg_upgrade does not upgrade pg_stat_statements properly