Re: Client application name

On Wed, 2009-10-21 at 10:45 +0100, Dave Page wrote:
> On Wed, Oct 21, 2009 at 10:40 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> > On Wed, 2009-10-21 at 10:19 +0100, Dave Page wrote:
> >> On Wed, Oct 21, 2009 at 10:14 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >>
> >> > ISTM much of the complexity discussed relates to this second feature.
> >> > Let's just concentrate on getting the connection-pool-identification
> >> > aspect of this done right and then maybe add second part later.
> >>
> >> That side of the patch works fine already (it's only a GUC after all),
> >> as does the during-connection option. The current problem is that old
> >> servers will barf if it's set in the startup packet.
> >>
> >> And yes, the stats part also works :-).
> >
> > Then I say this feature is good to go. It's much needed. Well done.
>
> Thanks.
>
> > Strip out the during-connection option for now. Let the startup packet
> > stuff come later, if ever.
>
> Either way there's a little work to do - if we forget about the
> startup packet (which I'd rather not do - I can see the value in
> having the app name in the connection log messages), I'll still need
> to tweak things such that libpq can set the GUC post-connection,
> either using the code Tom mentioned yesterday, or just issuing an
> explicit SET.

The SET seems sufficient for me. All interfaces currently support it.

The reason we want this is because the app name is not available at
connection time. It will only ever be NULL in the connection log
messages in the cases where this is most needed. In other cases, the app
name is not uniquely associated with a session and can change over time.
What value is there in knowing the app name at connection? Could we not
just log the app name iff log_connections is enabled?

Also, adding something to libpq means we have to alter all the clients
and that means they become incompatible with earlier versions. What
advantage comes from doing all of that work? Nothing even close to large
enough to warrant the pain and delay, AFAICS.

--
Simon Riggs www.2ndQuadrant.com