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