Re: Client application name - Mailing list pgsql-hackers

From Dave Page
Subject Re: Client application name
Date
Msg-id 937d27e10910210249i6f188d16u70c9cbc89e7d5a45@mail.gmail.com
Whole thread Raw
In response to Re: Client application name  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Client application name
Re: Client application name
List pgsql-hackers
On Wed, Oct 21, 2009 at 10:14 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:

> Looking at the way we process the startup packet in
> ProcessStartupPacket, there's one dirty hack you could do. As the code
> stands, if you specify "options" key/value pair more than once, the
> latter value overrides the first one. If we change that in PG 8.5 so
> that the values are concatenated instead, you can put app name into the
> first "options" line, and other options (or an empty string) into the
> second. Pre-8.5 servers will silently ignore the first line.

Not sure I follow - are you suggesting I set the appname via the
backend command line options? Currently I just send the
"application_name" as an explicit key/value pair.

> Another idea is to do something similar to the 'prefer' SSL mode, or if
> the server doesn't support protocol version 3: Try with the GUC in
> startup packet first, and if that fails, retry without it.
>
> I'm not sure if I like either of those better than the extra SET
> command, but I thought I'd mention it.

The command line sure seems ugly if that's what you meant. Retrying
doesn't seem so bad, though it'll still litter server logs with
connection errors.

-- 
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
PGDay.EU 2009 Conference: http://2009.pgday.eu/start


pgsql-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: Client application name
Next
From: Peter Eisentraut
Date:
Subject: Re: Could regexp_matches be immutable?