On 24/07/10 13:23, Greg Smith wrote: > Joshua Tolley wrote: >> Relatively minor, but it would be convenient to avoid having to query >> $external_pooler to determine the client_addr of an incoming connection. >> > > You suggest this as a minor concern, but I consider it to be one of the > most compelling arguments in favor of in-core pooling. A constant pain > with external poolers is the need to then combine two sources of data in > order to track connections fully, which is something that everyone runs > into eventually and finds annoying. It's one of the few things that > doesn't go away no matter how much fiddling you do with pgBouncer, it's > always getting in the way a bit. And it seems to seriously bother > systems administrators and developers, not just the DBAs. Putting a pooler in core won't inherently fix this, and won't remove the need to solve it for cases where the pooler can't be on the same machine. 9.0 has application_name to let apps identify themselves. Perhaps a "pooled_client_ip", to be set by a pooler rather than the app, could be added to address this problem in a way that can be used by all poolers new and existing, not just any new in-core pooling system. If a privileged set of pooler functions is was considered, as per my other recent mail, the pooler could use a management connection to set the client ip before handing the connection to the client, so the client couldn't change pooled_client_ip its self by accident or through malice. But even without that, it'd be awfully handy. -- Craig Ringer -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
