Re: [postgres_fdw] add local pid to fallback_application_name - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [postgres_fdw] add local pid to fallback_application_name
Date
Msg-id 714523.1627571201@sss.pgh.pa.us
Whole thread Raw
In response to [postgres_fdw] add local pid to fallback_application_name  ("kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>)
Responses RE: [postgres_fdw] add local pid to fallback_application_name  ("kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
"kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.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



pgsql-hackers by date:

Previous
From: Dave Cramer
Date:
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly