Application name patch - v4
in [PgSql]
|
Prev: Backup history file should be replicated in Streaming Replication?
Next: [PATCH] hstore documentation update
From: Tom Lane on 1 Dec 2009 13:25 Marko Kreen <markokr(a)gmail.com> writes: > If the pooler gets new connection with same username:database > as some existing connection, but with different appname, > what it is supposed to do? Whatever it wants to. People seem to be imagining that the appname isn't under the control of the pooler. It's a connection property, remember? It won't be set at all unless the pooler explicitly sets it or allows it to be set. I would imagine that typically a pooler would consider the whole connection string as defining connection properties and so appname would work the same as username or anything else, ie, you get shunted into a different connection pool if you ask for a different appname. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Marko Kreen on 1 Dec 2009 15:07 On 12/1/09, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Marko Kreen <markokr(a)gmail.com> writes: > > If the pooler gets new connection with same username:database > > as some existing connection, but with different appname, > > what it is supposed to do? > > > Whatever it wants to. People seem to be imagining that the appname > isn't under the control of the pooler. It's a connection property, > remember? It won't be set at all unless the pooler explicitly sets it > or allows it to be set. > > I would imagine that typically a pooler would consider the whole > connection string as defining connection properties and so appname would > work the same as username or anything else, ie, you get shunted into > a different connection pool if you ask for a different appname. No, at least both pgbouncer and pgpool consider only (username, database) pair as pool identifier. Rest of the startup params are tuned on the fly. And I think that should stay that way. Instead, could we make it equal to rest of startup params and track it's changes via ParamStatus? That makes it possible for poolers to handle it transparently. (IOW, you can put several poolers between client and server and nothing breaks) -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 1 Dec 2009 15:18 Marko Kreen <markokr(a)gmail.com> writes: > No, at least both pgbouncer and pgpool consider only (username, database) > pair as pool identifier. Rest of the startup params are tuned on the fly. > And I think that should stay that way. If you're happy with handling the existing connection parameters in a given way, why would you not want application_name behaving that same way? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Marko Kreen on 1 Dec 2009 16:08 On 12/1/09, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Marko Kreen <markokr(a)gmail.com> writes: > > > No, at least both pgbouncer and pgpool consider only (username, database) > > pair as pool identifier. Rest of the startup params are tuned on the fly. > > And I think that should stay that way. > > > If you're happy with handling the existing connection parameters in a given > way, why would you not want application_name behaving that same way? Well, in pgbouncer case, the parameters tracked via ParamStatus are handled transparently. (client_encoding, datestyle, timezone, standard_conforming_strings) Any other parameter is handled via "ignore_startup_parameters" option: if client supplies random option not appearing there, it is kicked out. The point being that as pgbouncer cannot handle it transparently, the admin needs to set the param in postgresql.conf if it is important, fix the client or let pgbouncer ignore it if client is unfixable. I have no problem handling appname with latter method, I just wanted to clarify the target audience for the feature. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 1 Dec 2009 16:20
Marko Kreen <markokr(a)gmail.com> writes: > On 12/1/09, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> If you're happy with handling the existing connection parameters in a given >> way, why would you not want application_name behaving that same way? > Well, in pgbouncer case, the parameters tracked via ParamStatus are > handled transparently. (client_encoding, datestyle, timezone, > standard_conforming_strings) Hmm, I had not thought about that. Is it sensible to mark application_name as GUC_REPORT so that pgbouncer can be smart about it? The actual overhead of such a thing would be probably be unmeasurable in the normal case where it's only set via the startup packet, but it seems a bit odd. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |