Re: Application name patch - v4 - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: Application name patch - v4
Date
Msg-id e51f66da0912010852n6f90d1d6v2f649e57ecf53da7@mail.gmail.com
Whole thread Raw
In response to Re: Application name patch - v4  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Application name patch - v4  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 12/1/09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dave Page <dpage@pgadmin.org> writes:
> > On Tue, Dec 1, 2009 at 4:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>  >> I don't think that we need to bump the protocol version.  The real
>  >> alternative here would be that libpq sends a startup packet that
>  >> includes application_name, and if it gets an error back from that,
>  >> it starts over without the app name.
>
>
> > I looked (briefly) at doing that when we first ran into this
>  > suggestion. As you pointed out at the time, it seemed like that would
>  > require some fairly ugly hackery in fe-connect.c
>
>
> Perhaps, but at the time it wasn't apparent that issuing a separate SET
>  would create user-visible behavioral inconsistencies.  Now that we've
>  realized that, I think we should reconsider.
>
>  If people are agreed that double connect is a better alternative
>  I'm willing to go look at how to make it happen.

Is it supposed to work with pooling or not?

If the pooler gets new connection with same username:database
as some existing connection, but with different appname,
what it is supposed to do?

-- 
marko


pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: [CORE] EOL for 7.4?
Next
From: Robert Gravsjö
Date:
Subject: Empty dictionary file when creating text search dictionary