Thread: Connecting over UNIX domain sockets
I would like to have the option to connect to the database over UNIX domain sockets (sidestepping the question of password management). Even though the JVM knows about UNIX domain sockets, this functionality is not exposed to user code, so we'd have to add some JNI code. Would you like to integrate this in some way? If yes, would you prefer a socket-based or libpq-based approach? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On 02/08/11 6:55 AM, Florian Weimer wrote: > I would like to have the option to connect to the database over UNIX > domain sockets (sidestepping the question of password management). > > Even though the JVM knows about UNIX domain sockets, this > functionality is not exposed to user code, so we'd have to add some > JNI code. Would you like to integrate this in some way? If yes, > would you prefer a socket-based or libpq-based approach? socket based would require less work, as you'd just add that to the existing socket code, while using libpq would essentially end up with an entirely different JDBC. managing and installing JNI based code across platforms is a pain in the sternum.
* John R. Pierce: > On 02/08/11 6:55 AM, Florian Weimer wrote: >> I would like to have the option to connect to the database over UNIX >> domain sockets (sidestepping the question of password management). >> >> Even though the JVM knows about UNIX domain sockets, this >> functionality is not exposed to user code, so we'd have to add some >> JNI code. Would you like to integrate this in some way? If yes, >> would you prefer a socket-based or libpq-based approach? > > socket based would require less work, as you'd just add that to the > existing socket code, while using libpq would essentially end up with > an entirely different JDBC. I would try to add a low-level read/write API to libpq. libpq would only handle configuration processing, authentication and the transport layer (which may include TLS). > managing and installing JNI based code across platforms is a pain in > the sternum. Some people do have working software distribution platforms. 8-) -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On 02/08/11 6:55 AM, Florian Weimer wrote: >I would like to have the option to connect to the database over UNIX >domain sockets (sidestepping the question of password management). > >Even though the JVM knows about UNIX domain sockets, this >functionality is not exposed to user code, so we'd have to add some >JNI code. Would you like to integrate this in some way? If yes, >would you prefer a socket-based or libpq-based approach? > >-- >Florian Weimer <fweimer(at)bfk(dot)de> >BFK edv-consulting GmbH http://www.bfk.de/ >Kriegsstraße 100 tel: +49-721-96201-1 >D-76133 Karlsruhe fax: +49-721-96201-99 Apologies for resurrecting an old thread, but I'm also interested in using domain sockets with postgres' jdbc driver. To any potential implementors, I wanted to point out something that might be useful... The junixsocket project (http://code.google.com/p/junixsocket/) provides an implementation of java.net.Socket that uses domain sockets. It also provides a mysql SocketFactory so that mysql's jdbc driver can be used with domain sockets. However, contrary to mysql's jdbc driver, postgres' jdbc driver does not appear to be designed in a way that a different Socket implementation could be easily "plugged in". If the postgres jdbc project does not want the full burden of managing the native code required for domain socket connectivity, perhaps one approach to take would be to refactor the postgres jdbc driver in such a way that a different mechanism for constructing sockets could be plugged in. Then an implementation could be provided by junixsocket, which already has the native distribution mechanism. Just a thought. Phil
On Mon, 2011-06-27 at 12:02 -0700, Phil Clay wrote: > Apologies for resurrecting an old thread, but I'm also interested in using > domain sockets with postgres' jdbc driver. > > To any potential implementors, I wanted to point out something that might be > useful... > > The junixsocket project (http://code.google.com/p/junixsocket/) provides an > implementation of java.net.Socket that uses domain sockets. It also provides a > mysql SocketFactory so that mysql's jdbc driver can be used with domain > sockets. > However, contrary to mysql's jdbc driver, postgres' jdbc driver does not appear > to be designed in a way that a different Socket implementation could be easily > "plugged in". Hmm - does pg jdbc driver support IPv6 ? If so, is it done inside java socket library ? > If the postgres jdbc project does not want the full burden of managing the > native code required for domain socket connectivity, perhaps one approach to > take would be to refactor the postgres jdbc driver in such a way that a > different mechanism for constructing sockets could be plugged in. Then an > implementation could be provided by junixsocket, which already has the native > distribution mechanism. > > Just a thought. > > Phil > -- ------- Hannu Krosing PostgreSQL Infinite Scalability and Performance Consultant PG Admin Book: http://www.2ndQuadrant.com/books/
On 06/28/2011 03:02 AM, Phil Clay wrote: > However, contrary to mysql's jdbc driver, postgres' jdbc driver does not appear > to be designed in a way that a different Socket implementation could be easily > "plugged in". There's already support for pluggable SSLSocketFactories to wrap sockets. Adding pluggable SocketFactory support wouldn't seem to be overly hard, I just suspect it's a combination of nobody having needed it and nobody having wanted it enough to take the time to write a patch. The JDBC driver is readable and not hard to understand, so maybe you could chuck a patch together? (Fighting very hard to say "Oh, I'll do something like that" when I've already volunteered for way too much). -- Craig Ringer
On 27/06/2011 23:20, Craig Ringer wrote:
> On 06/28/2011 03:02 AM, Phil Clay wrote:
>
>> However, contrary to mysql's jdbc driver, postgres' jdbc driver does
>> not appear
>> to be designed in a way that a different Socket implementation could
>> be easily
>> "plugged in".
>
> There's already support for pluggable SSLSocketFactories to wrap
> sockets. Adding pluggable SocketFactory support wouldn't seem to be
> overly hard, I just suspect it's a combination of nobody having needed
> it and nobody having wanted it enough to take the time to write a patch.
Hello,
I'm not sure if anyone had done any further work on this thread, but
here is a tentative patch (I've written it against the 8.4 code base) to
be able to use a custom SocketFactory (in particular for junixsocket).
This relies on two new properties:
- socketfactory, for the class name of the SocketFactory.
- socketfactoryarg, for the String argument of this SocketFactory
constructor.
I've changed this constructor into two:
- public PGStream(String host, int port)
+ public PGStream(String host, int port, SocketFactory socketFactory)
+ public PGStream(String host, int port, Properties info)
The one that uses Properties reads the properties to instantiate the
SocketFactory (via a new method PGStream.createSocketFactory(Properties
info), which is a very similar to the way the SSLSocketFactory is
instantiated).
The one that uses a SocketFactory can be used directly, but the main
reason I've introduced it was for PGStreams creates from other PGStreams
(the ones called "cancelledStream").
The only glitch was in PGStream.changeSocket(...), since AFUNIXSocket
(from junixsocket) doesn't support setTcpNoDelay (and throws an
exception). I made it catch any SocketException: although it could catch
AFUNIXSocketException (which extends SocketException), this would make
the driver depend on junixsocket.
- connection.setTcpNoDelay(true);
+ try {
+ connection.setTcpNoDelay(true);
+ } catch (SocketException e) {
+ // Ignore if the operation wasn't supported.
+ }
I'm also attaching a sample PgJdbcUnixSocketFactory to use this with
junixsocket (which needs to be on the classpath and have
'java.library.path' configured to point to its native libraries).
The following works, using a unix socket.
Properties props = new Properties();
props.setProperty("user", "name");
props.setProperty("password", "xxxxxx");
props.setProperty("socketfactory", "jdbctest.PgJdbcUnixSocketFactory");
props.setProperty("socketfactoryarg", "/tmp/.s.PGSQL.5432");
Connection jdbcConnection =
DriverManager.getConnection("jdbc:postgresql://", props)
To specify which database is to be used, it's possible to use something
like this:
DriverManager.getConnection("jdbc:postgresql://.../dbname", props)
(What's in "..." doesn't really matter, but "jdbc:postgresql:///dbname"
doesn't work.)
I'm not sure how these changes would fit with the rest of the design of
the driver, as I must admit I don't know this code very well. I suppose
there are multiple ways of implementing this feature, but I hope this
patch may be a sufficient starting point.
Best wishes,
Bruno.