Skip site navigation (1) Skip section navigation (2)

Re: pg_stat_activity.application_name

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_stat_activity.application_name
Date: 2009-07-16 19:37:42
Message-ID: 407d949e0907161237r76ebd92av6836c6563d8a230e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jul 16, 2009 at 8:08 PM, Kevin
Grittner<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> On the admin list there was a request for an application name
> column in pg_stat_activity.
>
> http://archives.postgresql.org/pgsql-admin/2009-07/msg00095.php
>
> This is available in a lot of other DBMS products, can be useful to
> DBAs, and seems pretty cheap and easy.  Could we get that onto the
> TODO list?

I think you should just add it.

Ok, we probably need some kind of policy for what to do before "just"
adding things to the TODO but I think it should be relatively liberal.
Something like, you should post that you're going to add it to the
-hackers list, get at least one person agreeing with the item and no
fatal flaws. Oh, and you should check for duplicates or for the same
item on the "things we don't want" list. But if having done that you
should assume it's up to you to just go ahead and add it.

In this case I don't see any harm in having an opaque application
identifier. Dangers (but surmountable ones I assume) would be:

1) The authenticity of the application identifier needs to be
downplayed -- don't even think of using it for security for example.

2) encoding issues if different connections are in different encodings...

3) backwards compatibility both in the library api and protocol

-- 
greg
http://mit.edu/~gsstark/resume.pdf

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2009-07-16 19:47:54
Subject: Re: Synch Rep for CommitFest 2009-07
Previous:From: Kevin GrittnerDate: 2009-07-16 19:33:53
Subject: Re: pg_stat_activity.application_name

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group