application_name in process name?

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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?

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers