Обсуждение: application_name in process name?
There are times when it would be useful to have the application_name connection parameter displayed in the process name - and thus in ps and pg_top - in addition to the user and database name.
Would there be any downside to this? If it were done, are there any suggestions on how it could be added the process name so as to minimize impact on anything that might be trying to parse that line?
__________________________________________________________________________________
Mike Blackwell | Technical Analyst, Distribution Services/Rollout Management | RR Donnelley
1750 Wallace Ave | St Charles, IL 60174-3401
Office: 630.313.7818
Mike.Blackwell@rrd.com
http://www.rrdonnelley.com
Mike Blackwell <mike.blackwell@rrd.com> writes: > There are times when it would be useful to have the application_name > connection parameter displayed in the process name - and thus in ps and > pg_top - in addition to the user and database name. > Would there be any downside to this? In a lot of situations ("top" for instance) only a limited number of characters can be displayed from a process title. I'm hesitant to add fields to that string that we don't really need. regards, tom lane
On 7/13/16 12:07 PM, Tom Lane wrote: > Mike Blackwell <mike.blackwell@rrd.com> writes: >> There are times when it would be useful to have the application_name >> connection parameter displayed in the process name - and thus in ps and >> pg_top - in addition to the user and database name. > >> Would there be any downside to this? > > In a lot of situations ("top" for instance) only a limited number of > characters can be displayed from a process title. I'm hesitant to add > fields to that string that we don't really need. Could we make this configurable, similar to log_line_prefix? -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532) mobile: 512-569-9461
Jim Nasby <Jim.Nasby@BlueTreble.com> writes: > On 7/13/16 12:07 PM, Tom Lane wrote: >> In a lot of situations ("top" for instance) only a limited number of >> characters can be displayed from a process title. I'm hesitant to add >> fields to that string that we don't really need. > Could we make this configurable, similar to log_line_prefix? Yeah, we could get rid of a lot of the need for value judgments in this area if we bit the bullet and provided infrastructure like that. It occurs to me that we could also remove the update_process_title GUC: what you would do is configure a process_title pattern that doesn't include the %-escape for current command tag, and the infrastructure could notice that that escape isn't present and skip unnecessary updates. The same kind of trick could be used for other potentially-expensive items like the lock "waiting" flag. regards, tom lane
It occurs to me that we could also remove the update_process_title GUC:
what you would do is configure a process_title pattern that doesn't
include the %-escape for current command tag, and the infrastructure
could notice that that escape isn't present and skip unnecessary updates.
The same kind of trick could be used for other potentially-expensive
items like the lock "waiting" flag.
This seems like an interesting project for learning my way around gucs and logging. Could you elaborate a little
on the cost considerations?
Mike Blackwell <mike.blackwell@rrd.com> writes: > On Sun, Jul 17, 2016 at 10:34 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> It occurs to me that we could also remove the update_process_title GUC: >> what you would do is configure a process_title pattern that doesn't >> include the %-escape for current command tag, and the infrastructure >> could notice that that escape isn't present and skip unnecessary updates. >> The same kind of trick could be used for other potentially-expensive >> items like the lock "waiting" flag. > This seems like an interesting project for learning my way around gucs and > logging. Could you elaborate a little > on the cost considerations? Well, the point is to avoid unnecessary updates of the process title, since on many platforms that involves a kernel call. Most of the fields that you might want in it are static anyhow, but current command tag obviously changes often, as does the lock-waiting annotation. The idea would be to notice that the selected title string doesn't call for those fields and skip updates if so. I envision this as having assignment of the process_title GUC compute a bitmask showing which possibly-mutable escape codes appear in the string (this could be implemented by having the check_hook compute a bitmask and save it via the GUC "extra" mechanism). Then calls to set_ps_display could be extended with a bitmask parameter showing which field types are known to be changing in that call, and you just "AND" to discover if an update is needed. regards, tom lane