Re: Application name patch - v4

On 12/1/09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine
> > <dfontaine(at)hi-media(dot)com> wrote:
> >> Le 30 nov. 2009 à 22:38, Robert Haas a écrit :
> >>> I still don't really understand why we wouldn't want RESET ALL to
> >>> reset the application name. In what circumstances would you want the
> >>> application name to stay the same across a RESET ALL?
> >>
> >> I can't see any use case, but SET/RESET is tied to SESSION whereas application_name is a CONNECTION property. So it's a hard sell that reseting the session will change connection properties.
>
> > Is there any technical difference between a connection property and a
> > session property? If so, what is it?
>
>
> The point is that every other thing you can set in a libpq connection
> string is persistent throughout the connection. For the ones that you
> can change at all, such as client_encoding, *RESET ALL actually resets
> it to what was specified in the connection string*. It does not satisfy
> the POLA for application_name to behave differently.

+1

This SESSION/CONNECITION terminology is confusing, better would be
talk about client connection/session (client->pooler) and server
connection/session (pooler->server) if you are talking about pooling.

> I think the argument about poolers expecting something different is
> hogwash. A pooler would want RESET ALL to revert the connection state
> to what it was at establishment. That would include whatever
> application name the pooler would have specified when it started the
> connection, I should think.
>
> The only reason we're even having this discussion is that libpq
> isn't able to make application_name work exactly like its other
> connection parameters because of the backwards-compatibility issue.
> Maybe we should think a bit harder about that. Or else give up
> having libpq manage it like a connection parameter.

Making it work in session pooling mode (pgpool) is easy - RESET ALL
and SET needs to work.

The question is whether it should work also in transaction
pooling mode (pgbouncer / JDBC). I see 2 variants:

1. Clients are allowed to specify it only in startup packet.
But, uh, poolers can set it also in the middle of session.

2. Make it into protocol-tracked variable.

The 1) seems inconsistent and backwards-incompatible - client does
not know server version yet and old servers dont accept it.

I don't see problems with 2).

Or we could decide it is not meant for transaction pooling environments.

--
marko