Le 04/01/2011 15:13, Guillaume Lelarge a écrit : > Hi, > > Le 04/01/2011 14:27, Jehan-Guillaume (ioguix) de Rorthais a écrit : >> [...] >> pgPool is currently using the parameter "backend_socket_dir" to define where >> it >> can find the backend unix socket files. >> >> However, from the libpq world, we just use one parameter for both unix or >> inet >> socket: host. If this parameter starts with '/', then this is a unix socket. >> All >> other values are inet connections. See: >> >> http://www.postgresql.org/docs/9.0/static/libpq-connect.html#LIBPQ-CONNECT-HOST >> >> Back in pgPool world, the equivalent parameter is "backend_hostnameN". So, >> when >> I was setting up a dev environment yesterday, I naturally set this parameter >> to >> my unix path (I'm using Debian) and end up with a hostname resolution error. >> >> So you'll find in attachment a patch to remove the "backend_socket_dir" >> parameter and use the libpq policy. Moreover, on empty "backend_hostnameN" >> value, the patch fall back to DEFAULT_SOCKET_DIR. >> > > This patch is really interesting. This is something I had on my todo > list for quite some time. > >> I realize it will break compatibility with older configuration file. But in a >> first step, I prefer something clean and start discussing this issue with >> you if >> you really mind this. >> > > On the configuration file, compatibility of configuration file is never > garantied. So I don't think this is such an issue. We need to make it > clear that the parameter has a new mail. >
.......................... has a new name. sorry about this :-/ -- Guillaume http://www.postgresql.fr http://dalibo.com _______________________________________________ Pgpool-hackers mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-hackers
