Craig Ringer <craig@2ndquadrant.com> writes:
> On 06/12/2013 02:24 PM, Tom Dunstan wrote:
>> Oh, interesting. Do the ruby/rails folks use that rather than a pure-ruby
>> driver? I guess I'm spoiled - most of my development happens on the JVM,
>> and the JDBC driver doesn't use libpq.
> Yes, they do - including a horde of deeply confused and frustrated Rails
> users struggling to understand why they're getting "no such file or
> directory" or "permission denied" messages about Pg's unix socket,
> because of course they're linked to Apple's libpq which has a different
> default unix socket path, and unless they explicitly specify `host:
> localhost` in their Rails database.yml they get a unix socket connection.
I poked at this a little bit, wondering whether it'd be practical to fix
the problem by configuring third-party postmasters to create a socket
where Apple's libpq is expecting. However, it looks like (in Lion
anyway) what libpq is expecting is this:
$ /usr/bin/psql -l
psql: could not connect to server: Permission denied Is the server running locally and accepting
connectionson Unix domain socket "/var/pgsql_socket/.s.PGSQL.5432"?
and that directory is configured with no public permissions at all:
$ ls -ld /var/pgsql_socket
drwxr-x--- 2 _postgres _postgres 68 Jun 13 2011 /var/pgsql_socket/
which basically means that no third-party code should ever be expecting
to communicate with a postmaster through there.
This being the case, I wonder if the Ruby PG gem shouldn't be written
to override the default socket location, which it could do with
something like
if (getenv("PGHOST") == NULL) putenv("PGHOST=/tmp");
without needing to muck with interpretation of connection strings.
Of course, if third-party packagings of PG aren't consistent about
where they think the socket goes, we won't know what to put there...
regards, tom lane