Re: Application name patch - v4
От | Marko Kreen |
---|---|
Тема | Re: Application name patch - v4 |
Дата | |
Msg-id | e51f66da0912010013l11ef65adx43a8ae9c8298f064@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Application name patch - v4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 12/1/09, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Mon, Nov 30, 2009 at 4:54 PM, Dimitri Fontaine > > <dfontaine@hi-media.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'sa 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
В списке pgsql-hackers по дате отправления: